System and method for transmitting broadcast television live service based on streaming protocol

Abstract

The application provides a system and method for transmitting broadcast television live broadcast services based on streaming media protocols, which comprises a platform-side media stream encapsulation gateway, a platform-side media stream multicast gateway, a core network multicast service relay transmission system, an access network station-side streaming media recombination gateway, an access network station-side integrated service gateway, an access network from the access network station to the user end, and a user end CPN network. The platform side transmits media protocol broadcast services according to multicast protocols. The access network station recombines CMAF media fragments, pulls list files and initializes fragments, and then accesses the CPN network with a user end home router as a gateway through an integrated service access network and broadband services and communication services, so as to realize unified access of three-network integration services.

Description

Technical Field

[0001] This application belongs to the field of network communication and multimedia transmission technology, and in particular relates to a system and method for transmitting live broadcast television services based on streaming media protocols. Background Technology

[0002] With the rapid development of ultra-high-definition (4K / 8K) video, interactive television, and other services, users have placed higher demands on the compatibility of these services with home networks. Currently, most live TV services are transmitted using UDP (User Datagram Protocol) multicast, IP broadcast, or DVB (Digital Video Broadcasting) technologies. While these technologies can fully meet the requirements of low-latency, high-quality live TV transmission, they suffer from insufficient compatibility with home networks and smart terminals, leading to inconvenience for users watching TV. If live TV is transmitted entirely using HTTP / TCP (Hypertext Transfer Protocol, Transmission Control Protocol) unicast, although this solves the compatibility issues with home networks and the integration of smart terminals, it would significantly increase the investment costs of core network CDN (Content Delivery Network) nodes and transmission bandwidth, and would also fail to meet the low-latency, high-efficiency transmission requirements of live TV services.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] The purpose of this application is to provide a method for transmitting live broadcast television services based on streaming media protocols, so as to solve the technical problem of insufficient compatibility of UDP multicast or IP broadcast live services with home networks and smart terminals.

[0005] A system for transmitting live broadcast television services based on streaming media protocols includes: a platform-side media stream encapsulation gateway, a platform-side media stream multicast gateway, a core network multicast service relay transmission system, an access network central office-side streaming media reassembly gateway, an access network central office-side integrated service gateway, an access network from the access network central office to the user end, and a user end CPN network, wherein: The platform-side media stream encapsulation gateway is used to receive platform-side TS / RTP multicast streams, and convert platform-side TS / RTP multicast streams into media fragments, initialize fragments and manifest files before connecting them to the platform-side media stream multicast gateway. The platform-side media stream multicast gateway is used to transmit the initialization fragments and manifest files to the access network office through the core network HTTP channel, and to convert and encapsulate the media fragments into CMA / RTP multicast streams, and then transmit them to the access network office through the core network in multicast relay mode. The core network multicast service relay transmission system is used to transmit the CMA / RTP multicast stream to the access network central office streaming media encapsulation gateway in multicast relay mode, so as to realize the purpose of transmitting streaming media protocol broadcast services in the core network through multicast protocol. The access network central office streaming media reassembly gateway is used to receive CMA / RTP multicast streams transmitted from the platform side to the access network central office through the core network multicast relay mode and reassemble media fragments. At the same time, it receives the manifest file and initial fragments corresponding to the media fragments through the HTTP channel, and rewrites the manifest file. After synchronizing the media fragments and the manifest file, it connects the initial fragments, manifest file and media fragments to the access network central office integrated service gateway. The access network central office integrated service gateway is used to provide DHCP service to user-end home routers, while providing integrated service services such as aggregation and routing forwarding for the original system communication services, broadband services and live streaming protocol output by the access network central office streaming media reassembly gateway; The access network from the central office to the user end provides a Layer 2 forwarding and optical or copper cable access carrier between the integrated service gateway at the central office and the CPN network at the user end, and is used for the integrated access of broadband services, communication services and live broadcast television streaming services from the integrated service gateway to the home CPN network. The user-side CPN network includes a home router and user terminals connected to the home router. The service side of the home router provides a WAN port for accessing the access network, and the user side of the home router provides a LAN port or WiFi interface for accessing user terminal devices to realize integrated service access. The terminal devices include at least one of the following: mobile phone, computer, and smart TV.

[0006] In one embodiment, the platform-side media stream encapsulation gateway includes: a TS / RTP packet receiving engine module, a cache management module, a TS packet demultiplexing and PES packet reassembly module, a PES packet parsing module, a CENC standard encryption module, a CMAF streaming media segmentation and encapsulation module, a segmentation and encapsulation initialization module, a CMAF streaming media segmentation writing module, a manifest file generation module, a first HTTP service module, and a second HTTP service module, wherein: The TS / RTP packet receiving engine module is used to receive the TS / RTP multicast stream output by the platform-side encoding cluster, and parse the TS / RTP packets or TS packets from the TS / RTP multicast stream. The TS / RTP packets or TS packets are then cached in the TS / RTP packet or TS packet cache area of ​​the cache management module so that the TS packets can be demultiplexed and read by the PES packet reassembly module. The TS packet demultiplexing module is used to read the TS / RTP packets or TS packets in the TS packet cache area of ​​the cache management module, and parse, demultiplex and reassemble the TS / RTP packets or TS packets to generate PES packets. The PES packets are then cached in the PES packet cache area of ​​the cache management module so that the PES packet parsing module can read them. The PES packet parsing module is used to read PES packets from the PES packet buffer of the cache management module, parse the access units composed of video NALU series and audio frames of the ES stream from the PES packets, perform sample processing on the access units to obtain clear stream samples, extract the sample-level metadata and encoding parameters of the clear stream samples, and write the display timestamp, decoding timestamp, frame type, sample size, access unit boundary flag and encoding parameters of the clear stream samples and sample-level metadata into the clear stream sample, sample metadata and encoding parameter buffer of the cache management module respectively; The CENC standard encryption module is used to read the clear stream sample and perform CENC standard encryption on the payload of the clear stream sample to obtain an encrypted sample. The encrypted sample is written into the encrypted sample cache area of ​​the cache management module. At the same time, the DRM encryption information metadata generated in the CENC standard encryption process is output and cached in the DRM encryption information metadata cache area of ​​the cache management module. The DRM encryption information metadata includes: initialization vector, encryption flag, encryption byte range, sample encryption information that can be loaded into the moof box part of the CMAF media segment, and default key ID, protection system specific header, SystemID, license access address, default IV size, encryption mode, and DRM system identifier that can be loaded into the moof box part of the initialization segment, so that the CMAF streaming media segment encapsulation module and the initialization segment encapsulation module can read it. The CMAF streaming media segment encapsulation module is used to read encrypted samples from the encrypted sample cache area of ​​the cache management module, while reading sample metadata from the PES packet sample metadata cache and DRM encrypted information metadata from the DRM encrypted information metadata cache. It encapsulates the samples into CMAF streaming media segments in units of closed GOPs with a duration of 2 seconds set by the encoder, and writes the CMAF streaming media segments into the media segment temporary cache area of ​​the cache management module so that the CMAF media segment writing module can read them. At the same time, it generates segment-level metadata of the CMAF streaming media segments based on the sample-level metadata of the CMAF streaming media segments and writes it into the segment-level metadata cache area of ​​the cache management module. The CMAF streaming media segment writing module is used to read the CMAF streaming media segments from the media segment temporary buffer of the cache management module and write them into the media segment publishing buffer of the cache management module. The initialization segment encapsulation module is used to read the encoding parameters in the encoding parameter cache and the metadata of the encrypted information in the DRM encryption information metadata cache and load them into the moov box. Based on the encoding parameters and DRM encryption information metadata, it encapsulates the initial segments required for media segment decoding and writes the initial segments into the initial segment cache of the cache management module. At the same time, it generates initial segment metadata based on the initial segments and writes it into the segment-level metadata cache of the cache management module. The manifest file generation module is used to read CMAF streaming media segment metadata and initialization segment metadata from the segment-level metadata cache area of ​​the cache management module, generate the HLSm3u8h / DASHmpd manifest corresponding to the CMAF media segment based on the CMAF streaming media segment metadata and initialization segment metadata, and write it into the manifest cache area of ​​the cache management module. The first HTTP service module provides an interface for the platform-side streaming media multicast gateway to pull CMAF streaming media segments, enabling protocol conversion from CMAF streaming media segments to CMA / RTP multicast. Simultaneously, when returning the pulled media segments, it writes the segment's start timestamp (PTS) into the HTTP header. It transmits the media segments and metadata using out-of-band metadata and a black-box data transmission mechanism. This allows the platform-side streaming media multicast gateway to obtain the PTS of a segment from the HTTP header without parsing the segment in the black box during the protocol conversion from RTP FU-A segmentation to CMA / RTP packets. The PTS is then written into the header of all CMA / RTP packets after the segment is cut, ensuring that all RTP packets of each media segment have the same timestamp, thus determining the attribution of CMA / RTP packets with the same timestamp to a single media segment. The second HTTP service module is used to provide the platform-side streaming media multicast gateway with a pull interface for retrieving the CMAF streaming media segment manifest file and initializing segments.

[0007] In one embodiment, the platform-side media stream multicast gateway includes: a CMAF fragment retrieval module, a cache management module, a CMA / RTP packet encapsulation module, a fragment initialization and manifest file retrieval module, a CMA / RTP multicast stream encapsulation module, and an HTTP service module, wherein: The CMAF segment retrieval module is used to retrieve CMAF media segments encapsulated and output by the platform-side media stream encapsulation gateway after scrambling according to the CENC standard via the HTTP interface. The retrieved media segments and the IDR frame timestamp (PTS) in the HTTP header are written to the media segment circular buffer and the PTS buffer, respectively, so that the CMA / RTP encapsulation module can read the media segments and the PTS of the IDR frame of the segment. The CMA / RTP packet encapsulation module reads complete CMAF media segments from the media segment circular buffer. It does not parse the media segments, treating them as binary black boxes to implement RTP FU-A binary segmentation. The segment size follows the TCP / IP protocol MTU value specification. Each media segment is divided into multiple RTP packet payloads, which are then encapsulated into RTP packets. Simultaneously, the timestamp PTS of the segment's IDR frame is read from the PTS buffer. A triple identifier—timestamp PTS, sequence number, and FU-A identifier—is injected into the header of the encapsulated RTP packet. This ensures that all RTP packets from the same media segment have the same timestamp, incrementing sequence numbers, and the FU-A identifier identifies the start and end of each CMAF media segment RTP packet. After CMA / RTP packet encapsulation, the packets are written to the CMA / RTP packet output queue buffer. The initialization fragment and manifest file retrieval module is used to retrieve the m3u8h / mpd manifest provided by the platform-side media stream encapsulation gateway via the HTTP channel, store it in the manifest cache, proxy it and provide it to the access network's streaming media reassembly gateway for retrieval. At the same time, it is also used to retrieve the initial fragments provided by the platform-side media stream encapsulation gateway and store them in the initialization fragment permanent cache. The CMA / RTP multicast stream encapsulation module is used to read media fragment CMA / RTP packets from the CMA / RTP packet output queue buffer, encapsulate them into CMA / RTP / UDP multicast streams, and then connect them to the core network multicast service relay transmission system. The core network multicast service relay transmission system then transmits the platform-side CMA / RTP / UDP multicast streams to the access network central office streaming media reassembly gateway. The HTTP service module provides an HTTP service interface for media manifests and initial fragments, enabling the access network's streaming media reassembly gateway to pull the m3u8h / mpd manifest and initialize fragments via HTTP service.

[0008] In one embodiment, the access network central office streaming media reassembly gateway includes: a CMA / RTP multicast stream to CMA / RTP layer parsing module, a cache management module, a CMA / RTP packet parsing module, a CMAF media fragment reassembly module, a manifest and initial fragment retrieval module, and a CMAF media fragment / manifest file / initial fragment HTTP service module, wherein: The CMA / RTP multicast stream is sent to the CMA / RTP layer parsing module, which receives the CMA / RTP multicast stream transmitted from the platform-side media stream multicast gateway through the core network multicast service relay system, parses out the CMA / RTP packets of the CMA / RTP multicast stream, and writes them into the CMA / RTP packet buffer area of ​​the cache management module for caching, so that the CMA / RTP packet parsing module can read and parse them. The CMA / RTP packet parsing module is used to read the CMA / RTP packets cached in the CMA / RTP packet cache area, parse out the RTP FU-A fragments of the RTP packet payload, and write them into the RTP FU-A fragment reassembly cache area according to the triple identifier of timestamp, sequence number and FU-A. The reassembly cache follows the triple identifier to ensure that the timestamp of the RTP packets of the same media fragment is the same, the sequence number is incremented, and the FU-A identifier determines the start and end of the fragment RTP packet. After all the RTP FU-A fragments of a media fragment are cached, the CMAF media fragment reassembly module is notified to read them. The CMAF media fragment reassembly module is used to read the CMA / RTP packet payload written to the reassembly buffer by the CMA / RTP packet parsing module. The reassembly buffer is a double buffer. When writing to one buffer, the RTP packet payload of the previous fragment is read from the other buffer. Writing and reading do not affect each other. Reading all the RTP packet payloads of a media fragment can reassemble a CMAF media fragment and write it to the CMAF media fragment circular buffer. The manifest and initial segment retrieval module is used to retrieve the m3u8h / mpd manifest and rewrite the media stream URL in the manifest. The URL points to the streaming media reassembly gateway to realize the synchronization of the media stream and manifest and store it in the manifest cache. At the same time, it retrieves the initial segments and stores them in the initial segment cache, so that the user terminal can retrieve the initial segments, m3u8h / mpd manifest and media segments. The CMAF Media Segmentation / Manifest File / Initialized Segmentation HTTP Service module is used to provide user terminals with the service of pulling media stream segments / initialized segments / media stream manifests by path. According to the user's request, it reads media stream segments / initialized segments / media stream manifests from the media segment cache, the initialized segment cache, and the manifest cache and forwards them to the user. Initialized segments support pre-fetching and random fetching services.

[0009] In one embodiment, the integrated service gateway includes: a high-speed interface and forwarding engine, a DHCP service module, a service identification and traffic splitting module, a policy control and QoS module, a session and resource management module, a configuration management module, a monitoring and alarm module, and a security and logging module, wherein: The high-speed interface and forwarding engine provide multiple 100G and multiple 10G high-speed northbound interfaces for accessing the original system BRAS, management platform, network management system, and access network central office streaming media reassembly gateway. These interfaces enable line-speed packet forwarding and system management. A 100G high-speed interface is provided to the original system BRAS to ensure access and forwarding of broadband, communication, and video-on-demand services. A 100G high-speed interface is also provided to the access network central office streaming media reassembly gateway to ensure access and forwarding of live streaming media protocols encapsulated and output by the gateway. The 10G interface can connect to the service management platform and network management system. 24 / 48 access is provided on the user side. 25G / 40G southbound interfaces, used to access 24 / 48 25G / 40G+48 The 1G / 10G interface access switch connects to the CPN network at the user end, which uses the home router as the gateway, to achieve converged access of broadband services, communication services, and streaming media protocol broadcast services. The DHCP service module is used to provide DHCP relay or DHCP service functions. In DHCP relay mode, the allocation and management of user terminal IP addresses are managed by the original system BRAS. In DHCP service mode, the DHCP service function of the original system BRAS is moved down to the integrated service gateway to provide DHCP service functions. The service identification and traffic splitting module is used to ensure that the original system's broadband and communication services are forwarded along the original path in DHCP relay mode, while enabling the newly added streaming media protocol live broadcast services to be forwarded locally without going through the original system's BRAS. The policy control and QoS module works in conjunction with the service identification and traffic distribution module to ensure local forwarding of streaming media protocol live services with high bandwidth and long connection characteristics through policy routing. The Session and Resource Management module, Configuration Management module, Monitoring and Alarm module, and Security and Log module are used to implement resource management, configuration management, log management, and security monitoring of the integrated gateway, providing control layer and management layer functions.

[0010] In one implementation, the out-of-band metadata and black-box transmission mechanism of the first HTTP service module is as follows: When the platform-side media stream multicast gateway pulls CMAF media fragments, the first HTTP service module reads the CMAF media fragments from the media fragment publishing cache, and simultaneously reads the fragment's IDR frame start timestamp (PTS) from the fragment-level metadata cache, encapsulates it into an HTTP return packet with the CMAF media fragment as the response body, and writes the fragment's start PTS into its HTTP header, thereby implementing the out-of-band metadata and black-box transmission mechanism; when transmitting each When CMAF media is fragmented, the PTS of the fragment is carried in the HTTP response header. This allows the platform-side media stream multicast gateway to receive the CMAF media fragment and cut it into CMA / RTP fragments without parsing the moof box of the media fragment to obtain its start timestamp (PTS). Instead, the PTS of the CMAF media fragment is obtained from its response header, and the CMAF media fragment is cut into CMA / RTP packet payloads as a binary black box and encapsulated into CMA / RTP packets. The out-of-band PTS is used as one of the triple identifiers of each CMA / RTP packet.

[0011] In one implementation, the CMA / RTP packet encapsulation module is used to treat CMAF media segments as black boxes to implement RTP FU-A binary segmentation. Each CMAF media segment is segmented into multiple RTP packet payloads, which are then encapsulated into RTP packets. The PTS of the segment's IDR frame is read from the PTS buffer. A triple identifier of timestamp, sequence number, and FU-A identifier is injected into the header of the segmented and encapsulated RTP packet to complete the CMA / RTP packet encapsulation. The packet is then written into the CMA / RTP packet output queue buffer. The triple identifier is as follows: the first identifier is the starting PTS of the first IDR frame of each CMAF media segment. All RTP packets of the same CMAF media segment are assigned this PTS to indicate that RTP packets with the same timestamp belong to the same CMAF media segment. The second identifier is the sequence number. Each segment's CMA / RTP packet sequence number increments continuously across segments to determine the order of RTP packets or detect packet loss. The incrementing sequence number across segments also provides the sorting order for the media segments. The third identifier is the FU-A identifier. S=1 and E=0 represent the first packet of a media segment, S=0 and E=0 represent intermediate packets, and S=0 and E=1 represent the last packet of the media segment. This identifies the start and end of the sorting of RTP packets for each segment, ensuring that all RTP packets in the same CMAF media segment have the same timestamp, incrementing sequence number, and the FU-A identifier that determines the start and end of the segment's RTP packets. This allows the receiving end to reconstruct and reassemble the CMAF media segment based on these three identifiers.

[0012] In one implementation, the service side of the platform-side media stream encapsulation gateway provides a 25G high-speed UDP interface to listen to and receive the TS / RTP multicast streams that are aggregated by the aggregation switch and broadcast in flood mode for each set of program encoding outputs on the platform side in promiscuous mode, thereby realizing the encapsulation of TS / RTP to CMAF media segments and the encapsulation output of corresponding list / initialization segments. The user side of the platform-side media stream encapsulation gateway provides a 100G media fragmentation interface and a 10G manifest / initialization fragmentation retrieval interface, which are used by the platform-side media stream multicast gateway to retrieve media fragments, manifests and initialization fragments. Requests and responses follow the principle of HTTP protocol that requests and responses are completed on the same TCP connection, and requests and responses for the same data are completed on the same interface. The service side of the platform-side media stream multicast gateway provides media segment retrieval and manifest / initialization segment retrieval interfaces corresponding to the user-side interface of the platform-side media stream encapsulation gateway. It retrieves media segments, manifest files, and initialization segments, and completes CMAF media segment to CMA / RTP multicast encapsulation and manifest / initialization segment proxy. For each program's media segments and manifest files, it retrieves them every 2 seconds to ensure that the manifest and media segment versions are consistent. It also retrieves them once when the initialization segment device starts up or when the version is updated. The user side of the platform-side media stream multicast gateway provides a 25G rate UDP interface for flooding CMA / RTP multicast streams and a 10G list / initial fragment HTTP pull interface, which are used by the access network's local-level media reassembly gateway to receive CMA / RTP multicast streams, list files, and initial fragments. The service side of the access network central office streaming media reassembly gateway provides a 25G multicast stream interface and a 10G HTTP interface corresponding to the user-side interface of the platform-side media stream multicast gateway. It listens for and receives CMA / RTP multicast streams in promiscuous mode, pulls the list and initializes fragments through the HTTP interface, parses the CMA / RTP multicast stream and reassembles each CMAF fragment. The user side of the access network central office streaming media reassembly gateway provides a 100G rate HTTP service interface for access network users to pull the manifest file, initialize fragmentation and media fragmentation; The generation time of a media segment is one GOP duration, that is, a media segment is generated every 2 seconds. Therefore, the time interval between fetching and multicasting a media segment is also 2 seconds. The cache management and segment fetching in each link must follow the media segment generation time and GOP duration to enable the segment to be broadcast or fetched as soon as it is generated, so as to ensure the pipeline production and supply of live streaming services from the platform side to the access network bureau side.

[0013] In one implementation, the platform encapsulates the live streaming service into media segment files and converts them into CMA / RTP multicast streams. It then transmits the CMA / RTP multicast streams of the CMAF media segment files using relay mode and transmits the media segment list and initialization segments using the HTTP channel. This decouples the low-frequency changing list and initialization segments from the high-frequency changing media segments. The media segments are transmitted through the multicast channel, and the list and initialization segments are transmitted through the HTTP channel, in order to preserve the standard of reliable transmission of the streaming media protocol and provide the terminal with standard streaming media protocol broadcast television live streaming services. The access network central office restores and reassembles the CMA / RTP multicast stream into CMAF media fragment files, enabling broadcast television live services, broadband services, and communication services to be transmitted to the user terminal via the TCP protocol, supporting reception and playback on various smart terminals.

[0014] A method for transmitting live broadcast television services based on the above-mentioned streaming media protocol includes: Receive TS / RTP multicast streams from existing live broadcast service platforms; The TS / RTP multicast stream is encapsulated into a CMAF media stream that is encrypted according to the CENC standard and managed by the DRM system key, along with the corresponding manifest file and initialization fragments; The CMAF media stream is converted into a CMA / RTP multicast stream, and the CMA / RTP multicast stream, along with the manifest file and initial fragmentation, is transmitted to the access network office via the core network relay transmission system and the HTTP channel. The access network central office receives the CMA / RTP multicast stream, reassembles and encapsulates the CMA / RTP multicast stream into original CMAF media fragments, and rewrites the URL of the manifest file to achieve synchronization between the manifest file and the reassembled CMAF media fragments. The reorganized CMAF media fragments, manifest files, and initial fragments are connected to the integrated services access network, along with broadband and communication services, and then connected to the CPN network with the user's home router as the gateway. This enables the converged access of broadband, communication, and live broadcast television services through a single network.

[0015] In the example above, the platform-side media stream encapsulation gateway receives the TS / RTP multicast stream from the live streaming service platform, parses out the video NALUs and audio frame samples, and encrypts and encapsulates them according to the CENC standard, outputting CMAF media fragments and corresponding manifests and initialization fragments. The platform-side media stream multicast gateway receives the aforementioned CMAF media fragments, manifests, and initialization fragments, and, using the RTPFU-A standard, cuts the CMAF media fragments into CMA / RTP payload fragments, encapsulates them into a CMA / RTP multicast stream, and broadcasts the CMA / RTP multicast stream and corresponding manifests and initialization fragments through the core network multicast relay transmission system in static multicast and HTTP modes. The access network's streaming media reassembly gateway receives the CMA / RTP multicast stream through the multicast channel, retrieves the corresponding manifests and initialization fragments through the HTTP channel, parses the CMA / RTP multicast stream, reassembles it into CMAF media fragments, and then connects the reassembled media fragments, the retrieved manifests, and the initialization fragments to the user terminal. This method fundamentally solves the technical problem of insufficient compatibility of UDP multicast or IP broadcast live streaming services with home networks and smart terminals. Attached Figure Description

[0016] 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 recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of a method for transmitting live broadcast television services based on a streaming media protocol, as provided in this application. Figure 2 This is a service processing time slot diagram of the method for transmitting live broadcast television services based on streaming media protocols provided in this application; Figure 3 This is a schematic diagram of the functional module of the TS / RTP multicast stream to CMAF media fragment (.M4s) media stream encapsulation gateway (device 1 data layer) provided in this application; Figure 4 This is a schematic diagram of the media stream multicast gateway (device 2 data layer) functional module for CMAF media fragments (.M4s) to CMA / RTP multicast streams provided in this application; Figure 5 This is a schematic diagram of the functional module of the streaming media reassembly gateway (device 3 data layer) for CMA / RTP multicast to CMAF media fragment (.M4s) provided in this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0019] It should also be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.

[0020] Currently, broadcast television networks use multiple modes to transmit live broadcast services, including dynamic multicast, static multicast, and DVB-C (Digital Video Broadcasting - Cable). This results in problems such as high access network costs and insufficient compatibility with home networks. Specifically: Dynamic multicast is a transmission technology for IPTV (Internet Protocol Television). IPTV networks rely on the IGMP (Internet Group Management Protocol) and PIM (Protocol Independent Multicast) protocols in the control plane and the UDP protocol in the data plane to transmit live programs. It relies on the IGMP protocol to manage group members and transmits MPEG-TS (MPEG Transport Stream) streams via the UDP protocol based on IP multicast technology. Terminals receive live services by joining the multicast group protocol. However, existing home network devices, such as home routers, do not adequately support IGMP and PIM protocols, and most existing televisions do not support IGMP by default. Therefore, it is necessary to configure a home gateway or home router that supports IGMP to solve the problem of IPTV set-top boxes and televisions not supporting IGMP. At the same time, during the transmission of IPTV (Internet Protocol Television) services, the transmission from the multicast source router to the host network segment router must go through multiple intermediate routers and replication points, and it mostly relies on PON (Passive Optical Network) network access. In order to save investment in core network and access network transmission bandwidth, the transmission bit rate of high-definition and ultra-high-definition programs in live broadcast services is greatly compressed. Even with the significant compression of the transmission bit rate, it is difficult for the packet loss rate to reach the broadcast-grade transmission standard.

[0021] Static multicast is a technology for transmitting live digital television programs using multicast (IP broadcast) technology without the IGMP protocol enabled. The data plane uses the same UDP multicast protocol technology as IPTV, and the TS packet encapsulation is the same as IPTV. However, the IGMP and PIM protocols are not enabled on the control plane. Static UDP multicast streams encapsulated with the UDP protocol are transmitted over a private network. Its transmission quality fully meets broadcast-grade transmission standards. However, home routers and televisions cannot directly receive static UDP multicast streams. Therefore, users need to configure a gateway that supports static UDP multicast stream reception or a set-top box that can receive UDP multicast streams in their homes. This involves dual access to the home via both broadband and broadcast networks, resulting in high access network costs.

[0022] DVB-C networks rely on QAM (Quadrature Amplitude Modulation) technology to transmit digital television programs. TCP / IP protocols, which transmit communication and internet services, do not support one-way broadcasting using QAM modulation. Therefore, in the convergence of communication, internet, and broadcast television services, both the DVB-C and broadband networks are connected to the home simultaneously. Furthermore, home routers do not support one-way broadcasting using QAM modulation. Consequently, users need to configure a DVB-C set-top box in their homes to receive and watch broadcast television programs.

[0023] The common problem with the above three models is their lack of compatibility with home networks, which means that users need to equip their homes with dedicated gateways and set-top boxes from operators. This not only results in high costs for network access but also makes watching TV extremely inconvenient for users.

[0024] The HLS / DASH (HTTP Live Streaming / Dynamic Adaptive Streaming over HTTP) media streaming protocol live streaming service system in the OTT (Over The Top, Internet TV / streaming service) mode can solve the compatibility problem of home networks, but it will bring great transmission pressure to the backbone network and metropolitan area network. This is because the live streaming service may experience a surge in concurrency during a certain period. To meet the concurrency pressure during this period, the core network needs to reserve sufficient bandwidth resources and a sufficient number of CDN nodes. The investment cost may be hundreds or thousands of times higher than the investment cost of the backbone network in the three modes mentioned above. At the same time, the entire network adopts the full OTT mode to transmit broadcast TV live streaming services, and the latency of the live streaming service cannot meet the low latency transmission requirements of broadcast.

[0025] This example provides a transmission solution that integrates UDP multicast, IP broadcast, or DVB broadcast technologies with HLS / DASH media streaming technology. This solution meets the low-cost, low-latency, and high-quality live TV service requirements of UDP multicast, IP broadcast, or DVB broadcast technologies. Simultaneously, considering the need for full compatibility with all smart terminals, it receives live TV programs encapsulated and forwarded from HLS / DASH media streams via HTTP / TCP protocol. This completely solves the technical problem of inconvenience for users watching TV due to insufficient compatibility of UDP multicast, IP broadcast, or DVB broadcast technologies with home networks. Furthermore, its investment and operating costs are close to or lower than those of existing access networks.

[0026] Based on this, this example provides a system and method for transmitting live broadcast television services based on streaming media protocols. The system includes a platform-side media stream encapsulation gateway (device 1), a media stream multicast gateway (device 2), an access network central office streaming media reassembly gateway (device 3), and an access network central office integrated service gateway (device 4). The platform-side media stream encapsulation gateway receives the TS / UDP multicast stream broadcast by the live broadcast service platform using static multicast. It parses the original video NALU (Network Abstraction Layer Unit) series and audio frame access units of each program's TS packet. After sampled, it encrypts the sampled NALU payload and audio frame samples using the CENC (Common Encryption) standard and encapsulates them into CMAF media fragments (.m4s). It initializes the fragments and the corresponding HLSm3u8h / DASHmpd manifest to support DRM (Digital Rights Management) clients and smart terminals of HLS / DASH media stream players, enabling direct reception and playback via a home router. Specifically: On the live streaming platform side, the live streaming services to be transmitted are encoded and compressed by the encoding cluster, and each program is encapsulated into a TS over RTP over UDP over IP multicast stream, which is then aggregated by the aggregation switch and broadcast as a static multicast stream. On the live streaming platform side, a media stream encapsulation network management system is configured to receive the aforementioned TS over RTP over UDP over IP multicast streams. It parses and demultiplexes the TS packets of each program and restores the original video NALU series and audio frame access units. After sampled, the video and audio access units are encrypted according to the CENC standard and encapsulated into CMAF media fragments (.m4s), and the fragments and corresponding HLSm3u8h / DASHmpd lists are initialized.

[0027] On the live streaming service platform side, another media stream multicast gateway is configured to convert the above-mentioned CMAF media segments (.m4s) into CMA / RTP multicast streams and broadcast the CMA / RTP multicast streams in static multicast mode. At the same time, the initial segment and HLSm3u8h / DASHmpd list are transmitted via HTTP protocol. The access network central office is configured with a streaming media reassembly gateway to receive the above-mentioned CMAF media fragment CMA / RTP multicast stream, initial fragments and corresponding HLSm / DASH manifest files transmitted by the platform side through the backbone network in a hybrid mode of static multicast + HTTP. After reassembling and encapsulating the original CMAF media fragments (.m4s), the initial fragments, manifest files and streaming media files are accessed to the end user through HTTP service mode. The user terminal supports smart terminals that support DRM clients and HLS / DASH media streaming players, enabling them to directly receive and play live streaming services that use UDP multicast streams from edge nodes to CMAF media segments via home routers.

[0028] Compared with the existing mode of using multiple CDNs to transmit HLS / DASH media streams, the method provided in this example can not only significantly save core network transmission bandwidth and CDN node investment costs, but also achieve low-latency transmission characteristics for broadcast television live services, so that the user's perception time for channel selection and switching of live programs is less than 500ms.

[0029] The platform converts TS / RTP multicast into CMAF media fragments (.m4s), then converts the CMAF media fragments (.m4s) into CMA / RTP multicast streams. In the core network, the CMA / RTP multicast streams, the manifest files corresponding to the original media fragments, and the initial fragments are transmitted via static multicast + HTTP. The access network is equipped with a streaming media reassembly gateway, which receives the CMA / RTP multicast streams, initial fragments, and HLSm3u8h / DASHmpd manifests transmitted from the core network to the access network in promiscuous mode (monitoring and HTTP pull mode). The received CMA / UDP multicast streams are reassembled and encapsulated to recreate the original CMAF media fragments (.m4s). After rewriting and synchronizing the fragment manifests, the data is transmitted to the end user via the access network. The user's smart TV or non-smart TV + set-top box mode receives and plays the CMAF media fragment (.m4s) live broadcast service through a home router. This method of transmitting broadcast television live services based on streaming media protocols solves the current problem of insufficient compatibility of multicast or DVB protocol live broadcast services with home networks or smart terminals.

[0030] The advantages of using streaming media protocols to transmit live broadcast television services are: The platform encapsulates the live streaming service in media stream format, and the user end receives the live streaming service in media stream format, which completely solves the problem of insufficient compatibility of existing multicast or DVB broadcast with home networks and access terminals. Various smart terminals can receive and play live streaming services in streaming media format without the need to be equipped with dedicated decoding equipment. The platform implements CENC standard encryption on the payload of the original video frame NALU and audio frame samples of the live broadcast service, and the DRM system manages the keys to fully ensure that the operator can manage and control the user level and terminal level. The broadcast end converts the CMAF media fragments (.m4s) of the live broadcast service into CMA / RTP multicast streams and broadcasts them in static multicast mode. In the core network, the CMA / RTP multicast streams are transmitted in multicast relay mode. The initial fragments and list parts are transmitted in HTTP protocol. There is no need to equip the backbone network with distribution systems such as routing, switching and replication points. Instead, the static multicast streams are transmitted using hub relay mode, realizing one-to-many distribution and many-to-one protection. The core network transmission bandwidth is always constant. The hub itself has the function of relaying and shaping digital signals, which can ensure high-quality transmission. Furthermore, the cost is far lower than the cost of complex distribution equipment such as routing and switching, thus meeting the characteristics of low-cost and high-quality transmission. The dual-end protocol conversion transmission mode of media files to multicast transmission and then back to the original media files can solve the problem of insufficient compatibility of multicast protocols with user terminals. Compared with the full HTTP mode transmission of media files, it can save a lot of investment costs in core network CDN nodes and transmission bandwidth. At the same time, it can make the transmission latency of media streaming services approach the low latency transmission of UDP multicast or DVB broadcast. The channel selection and switching time can be reduced to 500ms compared with the high latency of 2 to 6 seconds when transmitting media files in HTTP mode. In the core network, CMA / RTP multicast streams are transmitted in a low-cost hub relay mode. The protection mode and transmission indicators of the transmission channel can achieve broadcast-level channel protection indicators and high-quality transmission indicators. The switching of primary and backup paths can be completed in milliseconds, and the packet loss rate is no more than one in a million.

[0031] The protocol conversion system and method for transmitting live broadcast television services based on streaming media protocols proposed in this disclosure have significantly lower investment and operating costs than existing IPTV networks and IP broadcast or DVB broadcast systems of cable television networks. At the same time, user terminals do not need to be equipped with dedicated private decoding equipment, which can solve the problem of repeated investment caused by the need to equip IPTV technology, IP broadcast and DVB broadcast access networks with dedicated decoding equipment at the user end and continuous upgrades, bringing operators a high return on investment.

[0032] like Figure 1The diagram shown illustrates a broadcast television live streaming service system based on streaming media protocols, as provided in this example. It includes: a service platform-side encoding cluster 0101, a content management system 0102, a service operation support system 0103, a key server 0104, a license server 0105, an authentication gateway 0106, a media stream encapsulation gateway 0107 (device 1), a media stream multicast gateway 0108 (device 2), a multicast repeater on the core network side 0109, a streaming media reassembly gateway on the access network central office side 0110 (device 3), an integrated service gateway 0111 (device 4), an access switch 0112 (device 5), home users 0113, and a user CPN network. The business platform side consists of an encoding cluster (0101), a content management system (0102), a business operation support system (0103), a key server (0104), a license server (0105), and an authentication gateway (0106), responsible for content injection, content management, content encryption, license services, business support, authentication management, and content services. The media stream encapsulation gateway (0107, device 1), the media stream multicast gateway (0108, device 2), the multicast repeater on the core network side (0109), the streaming media reassembly gateway on the access network side (0110, device 3), the integrated service gateway (0111, device 4), the access switch (0112, device 5), the home user (0113), and the user CPN network, responsible for efficient protocol conversion and content distribution.

[0033] The business platform-side encoding cluster 0101 consists of a multi-channel program encoding and multiplexing unit. Each encoder receives one channel of baseband audio and video stream and encodes and compresses it into a continuous stream according to the GOP (Group of Pictures) setting value. This means that multiple B and P frames are inserted between the start of an IDR frame and the beginning of the next IDR frame. Each frame can consist of one or more NALUs, and each GOP begins with an IDR (Instant Decoder Refresh) frame to allow for independent playback. Its structure is IBBPBBPBBPBBPBB frames. Although the encoder outputs a continuous video frame NALU stream and an audio frame ES stream according to the GOP setting value, it must also comply with the encoder's intelligent switching function. For example, when a scene change is detected, even if the GOP length has not reached the set length, a new GOP starting with an I frame may be automatically started. However, in live streaming systems, to simplify system complexity, the encoder's intelligent switching function is generally disabled, ensuring that each GOP is a closed GOP, and requiring the GOP length to be exactly equal to one CMAF (Common Media Application). The length of a CMAF segment (General Media Application Format) is defined as follows: if a CMAF segment contains only this one segment, then the segment, segment, and GOP have a one-to-one correspondence.

[0034] The aforementioned closed GOP requires that the starting I-frame of each GOP be an IDR frame. The one-to-one correspondence between Segment, Fragment, and GOP is as follows: the GOP duration is determined at the coding layer to be 2 seconds and starts with an IDR frame; one CMAF Fragment encapsulates one GOP at the encapsulation layer; and one CMAF Segment at the fragmentation layer typically contains only one CMAF Fragment, directly corresponding to an entry in the list. Through this strict alignment relationship, independent decoding of fragments, seamless switching, and low-latency transmission can be achieved.

[0035] Each encoder in the 0101 encoding cluster on the service platform side fulfills the functions of encoding, compression, and multiplexing of the baseband video for each program. First, it completes the encoding and compression to output the ES stream of the video NALU series and audio frames. Then, it encapsulates the ES stream into video PES stream and audio PES stream by access unit. The PES packet header is written with the decoding timestamp DTS and display timestamp PTS. After the encapsulation and multiplexing of PES packets into TS packets (including the creation and encapsulation of PAT / PMT tables), it outputs a multicast stream of TS over RTP over UDP over IP, and connects to the media stream encapsulation gateway 0107 (device 1) on the platform side through the aggregation switch. The media stream encapsulation gateway 0107 (device 1) receives the multicast stream (TS over RTP over UDP over IP) output by the encoder of the live streaming service platform. After restoring the audio and video PES packets and parsing out a series of continuous video NALUs and audio frame access units of the ES stream, it encrypts and encapsulates them into CMAF media segments (.m4s) defined by closed GOPs. A GOP with a length of 2s includes a series of continuous audio and video sample units, starting with an I-frame followed by several B-frames and P-frames in a continuous IBBPBBPBBPBBPBB ES stream. The NALUs and audio frame samples of the ES stream are encrypted and encapsulated according to the CENC standard into CMAF media segment .m4s media files, corresponding manifest files, and initialization segments. Moreover, a CMAF media segment (.m4s) contains at least one complete GOP, a GOP contains multiple video samples (frames), a video sample (frame) consists of one or more NALUs, and a CMAF segment (.m4s) contains at least one complete GOP. That is, a CMAF fragment (.m4s) can encapsulate one or more GOPs, and each GOP must be complete and guaranteed to start with an IDR frame so that each fragment can be played independently.

[0036] In the process of the media stream encapsulation gateway 0107 (device 1) receiving the TS / RTP multicast stream output by the encoder, parsing and demultiplexing it to obtain continuous image frames, and encapsulating them into CMAF media fragment .m4s media files, the first step is to perform CENC standard encryption on the video frame and audio frame samples, and then encapsulate the encrypted samples into CMAF media fragment .m4s media files. The encryption can be encryption of the complete sample frame or encryption of the NALU payload within the sample. Specifically, the CENC encryption and CMAF fragmentation encapsulation gateway device 1 requests a key from the key server 0104, obtains CK and KID, encrypts the sample frame or NALU payload, and encapsulates it into a .m4s media file of CENC standard encrypted CMAF media fragments. Simultaneously, it generates a corresponding HLSm3u8h / DASHmpd manifest and initializes the fragments. The encrypted and encapsulated CMAF media fragment .m4s media file, the corresponding HLSm3u8h / DASHmpd manifest, and the initialized fragments are cached in the corresponding buffer. HTTP1 and HTTP2 interfaces are provided so that the platform-side media stream multicast gateway 0108 (device 2) can retrieve the CMAF media fragment .m4s media file, the corresponding HLSm3u8h / DASHmpd manifest, and the initialized fragments, thus achieving protocol conversion from media stream to multicast stream. Simultaneously, the key server securely synchronizes the encryption key to the license server 0105 so that the DRM terminal can obtain the key to decrypt and play the CENC standard encrypted CMAF media fragment .m4s media file.

[0037] The scrambler / encryptor encrypts (scrambles) the payload of the sample or NALU using the content key (CK). Simultaneously, it inserts DRM metadata, which includes at least the KID (Key Identifier) ​​and the license server URL. KID (Key ID): A unique identifier used to identify the content key (CK) used for the currently encrypted content. When the client needs to decrypt, it sends this KID to the license server to request the corresponding CK. The URL is the address of the license server; the client uses this URL to request a license (which includes the CK and usage rules). CK (Content Key): The content key, i.e., the symmetric key actually used to encrypt the media stream, is typically an AES (Advanced Encryption Standard) key. The CK itself resides on the license server and is not directly transmitted; instead, it is encrypted (e.g., using a device public key or shared key) and included in the license before being sent to the client.

[0038] The media stream multicast gateway 0108 (device 2) on the platform side pulls CMAF fragments encapsulated and output by the media stream encapsulation gateway through the HTTP1 interface for media fragment retrieval, and pulls the manifest file and initializes the fragments through the HTTP2 interface. When each media fragment is cut and encapsulated into CMA / RTP packets according to FU-A, in order to fully comply with the RTP standard (such as RFC 3550) specification, the start timestamp PTS of the fragment is written into the header of all CMA / RTP packets of each fragment to maintain a precise correspondence with the original TS stream and the original fragment timeline. This ensures that the time order of the original fragments can be correctly restored during reassembly at the access network central office, mapping "one fragment" to "one logical frame". In this example, a transmission scheme with external metadata and black-box transmission is adopted. Specifically, the media stream encapsulation gateway 0107 (device 1) encapsulates the CMAF media fragment (.m4s) and the corresponding HLSm3u8h / DASHmpd manifest file and initializes the fragment. Simultaneously, it generates a metadata file containing the media fragment start timestamp required by the media stream multicast gateway 0108 (device 2). When device 2 requests a media fragment, device 1 provides the CMAF fragment start timestamp PTS in the HTTP response header of the returned media fragment, based on the original data file. For example: X-Timestamp: 90000 (RTP timestamp, 90kHz clock) X-Duration: 2.0 (Fragment Duration, seconds): Regardless of whether a CMAF media fragment encapsulates one or multiple GOPs, the start timestamp of the first IDR frame in the first GOP is copied and provided to Device 2. Device 2, without needing to parse the media fragment, initialize the fragment, or the manifest, obtains the start timestamp (PTS) of the first IDR frame for that fragment from the HTTP response header in "out-of-band metadata and black-box transmission" mode. This timestamp is injected into each RTP packet when the fragment is divided into multiple RTP packets, ensuring that all RTP packets of a CMAF fragment have the same timestamp. This allows the access network central office to reassemble fragments, assigning RTP payloads with the same timestamp to the same media fragment. The original CMAF media fragment (.m4s) is then reassembled based on a triple mechanism of timestamp, sequence number, and FU-A identifier. Specifically, this may include: 1) Media stream encapsulation gateway 0107 (device 1) generates metadata during media fragment encapsulation: When device 1 generates a CMAF media fragment (.m4s file), it also generates a corresponding metadata file or database record, which includes: fragment start timestamp (PTS of the first sample), fragment duration, fragment sequence number, and may also include KID, encryption information, etc. For example: X-Fragment-Timestamp: 90000 (PTS of the first sample (IDR frame) within this fragment); X-Fragment-Duration: 2000 (fragment duration); X-Fragment-Sequence: 12345 (fragment sequence number).

[0039] 2) Storage format of metadata: File system: Each shard file is accompanied by a .meta file with the same name (e.g., seg_12345.m4s.meta), which contains metadata in JSON or binary format.

[0040] Database: Store metadata in an in-memory database (e.g., Redis) or a relational database, using the shard URL or sequence number as the key.

[0041] File name encoding: Encode key information in the file name (e.g., seg_12345_90000_2000.m4s).

[0042] 3) HTTP service logic: When device 2 requests GET / ch1 / seg_12345.m4s, the upstream device 1's HTTP server (e.g., Nginx + Lua / OpenResty, or a customized Go service) performs the following: parses the channel and fragment identifier from the request URL; quickly queries the corresponding metadata from the metadata store (memory operation, microsecond level); writes the metadata (X-Fragment-Timestamp, etc.) into the HTTP response header; and sends the fragment file content using sendfile or zero-copy.

[0043] The returned HTTP response is: HTTP / 1.1 200 OK Content-Type: video / mp4 ← Standard header: Indicates the response body is an MP4 file. Content-Length: 123456 ← Standard Header: Response Body Byte Count X-Timestamp: 90000 ← Custom header: Segment start PTS (90kHz) X-Duration: 2000 ← Custom header: Shard duration (milliseconds) X-Sequence: 12345 ← Custom header: Fragment sequence number Cache-Control: no-cache ← Standard header: Disable caching ← Blank line (separates the head and body) [Binary data: contents of the seg_12345.m4s file] ← Response body Specifically, X-Fragment-Timestamp refers to the start timestamp of the fragment it belongs to. In typical encapsulation, this start timestamp is the PTS of the first IDR frame of that fragment. X-Fragment-Timestamp is a custom field carried in the HTTP response or request header, used to inform device 2 of the fragment's position on the timeline before the fragment's data body is fully received or parsed. Therefore, X-Fragment-Timestamp marks the start time base of the entire fragment, rather than a specific frame. In typical low-latency live streaming encapsulation specifications (e.g., LL-HLS, LHLS), to support seamless switching and random access, a media fragment is typically designed to start with a keyframe (an IDR frame in the video track) and contain a complete GOP. However, the 0101 encoding cluster on the business platform side already specifies that the GOP length must be equal to the length of a CMAF Fragment. In this case, if a CMAF Segment contains only one Fragment, then the Segment, Fragment, and GOP have a one-to-one correspondence. Furthermore, the GOP must be a closed GOP, and a media segment must encapsulate only one Fragment with a duration of 2 seconds. Therefore, the start time of this segment equals the decoding / display time of the first sample within the segment, meaning the first sample within the segment equals the IDR frame. Thus, X-Fragment-Timestamp ≈ Segment start time ≈ IDR frame PTS. Its function is equivalent to the tfdt box in the standard but earlier. In the standard ISOBMFF segment, the same time reference information is stored in the moof->tfdt box.

[0044] By carrying this information additionally at the HTTP protocol layer, the X-Fragment-Timestamp allows the media stream multicast gateway 0108 (device 2) to obtain the timestamp of the first IDR frame of a media segment in advance and accurately without parsing the entire media segment moof box. This enables the media segment to be treated as a "black box" or binary data block. Using the RTP FU-A standard, this black box is cut into small segments of RTP payload, encapsulated into RTP packets, and the X-Fragment-Timestamp carried additionally at the HTTP protocol layer is injected into the header of all RTP packets of that segment. This ensures that the timestamp identifier of the RTP packets after each media segment is divided is the same, thereby determining the ownership of the RTP packets.

[0045] It should be clarified that the out-of-band timestamps mentioned above are only used for the timestamps of the segmented CMA / RTP packets. The sample timestamp metadata within each segment is still in the metadata of the media segment. The receiving end uses the RTP packet timestamps mentioned above to reassemble the media segments and decodes and plays them according to the metadata of the media segments in DTS / PTS.

[0046] The multicast repeater 0109 on the core network side transmits CMAF media fragments (.m4s) media files in relay mode within the core network. These fragments are segmented into RTP payloads using the RTP FU-A standard and encapsulated into CMA / RTP Over UDP Over IP packets. This differs from transmitting CMAF media fragments (.m4s) media files using HTTP technology within the core network. It eliminates the need for significant investment in CDN nodes and transmission bandwidth within the core network. Instead, it utilizes a relay technology with extremely low cost, higher transmission quality, and lowest transmission latency. Its packet loss rate can be as low as 0.0001%, and its transmission quality is far superior to that of transmitting via HTTP+CDN nodes across the entire network, while also having a lower overall cost.

[0047] The access network's streaming media reassembly gateway device 3 receives the CMA / RTP Over UDP Over IP multicast stream, initial fragments, and corresponding HLSm3u8h / DASHmpd lists from the platform side via the core network in RTP and HTTP modes. It then parses the RTP layer payload fragments of the CMA / RTP multicast stream and reassembles each consecutive RTP fragment into consecutive original CMAF media fragments (.m4s) using a triple mechanism of sequence number, timestamp, and FU-A tag. Simultaneously, it obtains the corresponding HLSm3u8h and DASHmpd lists and initial fragments via the HTTP interface. After rewriting and encapsulating the lists, it reassembles the complete CMAF media fragments (.m4s), corresponding HLSm3u8h and DASHmpd lists, and initial fragments. The fragments are forwarded to the cache management module for caching. This allows the HTTP service unit to quickly read the user-requested HLSm3u8h and DASHmpd files, the corresponding CMAF media fragment (.m4s) files, and initialize the fragments from the cache according to the user's smart terminal request. The fragments are then forwarded to the destination user through the media stream interface. This enables efficient transmission of live streaming media streams with DRM standard encryption and access services for smart terminals. It supports access from set-top boxes and non-smart TVs, as well as access from mobile phones, computers, and smart TVs. The CENC standard encryption and DRM key management mechanism ensure that operators can manage and control all terminals.

[0048] During the transmission of CMAF media fragments (.m4s), initialization fragments, and corresponding HLSm3u8h / DASHmpd lists from the platform side to the access network central office using RTP and HTTP modes, the system only performs CMA / RTP Over UDP multicast protocol conversion on the original CMAF media fragments (.m4s) output by device 1, and transmits the CMA / RTP Over UDP multicast stream to the access network central office using static multicast technology. The access network central office parses out the CMA / RTP fragments and reassembles and encapsulates the original CMAF media fragments (.m4s). However, the initialization fragments and HLSm3u8h / DASHmpd lists are still transmitted using the HTTP protocol. After receiving the initialization fragments, HLSm3u8h, and DASHmpd lists output by device 1 through the HTTP channel, device 2 on the platform side also relays them to device 3 at the access network central office through a separate HTTP channel. Device 3 receives the CMA / RTP Over UDP multicast stream through the RTP relay channel. While streaming the UDP multicast stream, the system receives the initialization fragments and manifest HLSm3u8h / DASHmpd via the HTTP channel. It reassembles the CMAF media fragments (.m4s) and rewrites the HLSm3u8h / DASHmpd manifest file to achieve synchronization between the manifest and the media fragments. The system then forwards the initialization fragments, manifest file, and media fragments according to terminal requests.

[0049] During the transmission of initialization fragments, manifest files, and media fragments, strict synchronization is maintained between the initialization fragments, the HLSm3u8h / DASHmpd manifest, and the reassembled original CMAF media fragments (.m4s). Specifically: Device 1 implements media segment encapsulation, manifest and initial segment generation; Device 2 implements media stream multicast and manifest proxy; Device 3 implements media segment reassembly, pulls initial segment and manifest, and rewrites manifest and media segment synchronization.

[0050] Assuming the system transmits 198 live broadcast programs, the multicast address and port number planned for the original CMAF media fragments (.m4s) to the CMA / RTP Over UDP multicast stream are as follows: 239.1.1.1:5000 239.1.1.2: 5000 ...... 239.1.1.198:5000 The entire process follows the principle of separation of control and data: Control channel (HTTP / TCP): Transmits initialization fragments and manifest files, requires reliability, but is not sensitive to bandwidth; Data channel (RTP / UDP multicast): transmits fragmented media, requires low latency and high throughput, and allows for a small amount of packet loss under FEC protection.

[0051] That is, the platform encapsulates the live streaming service into media segments (.m4s) files and converts them into CMA / RTP multicast streams. It then uses relay mode to transmit the CMA / RTP multicast streams of the CMAF media segments (.m4s) files, saving on CDN node and high transmission bandwidth investment costs.

[0052] By using the HTTP channel to transmit media fragment manifests and initial fragments, control and data are truly separated. The low-frequency changing static metadata (manifests, initial fragments) is completely decoupled from the high-frequency changing media stream (media fragments). The multicast channel improves the efficiency of media stream transmission and reduces transmission costs, while the HTTP channel transmits static metadata (manifests and initial fragments), preserving the standard specifications for reliable transmission of streaming media protocols and providing terminals with standard streaming media protocol broadcast television live services.

[0053] The access network central office restores and reassembles the CMA / RTP multicast stream into CMAF media fragments (.m4s) files, enabling broadcast television live services, broadband services, and communication services to be accessed to the user terminal together via the TCP protocol, fully supporting access from various smart terminals.

[0054] In one embodiment, this application provides a data processing flow for transmitting live broadcast television services based on a streaming media protocol, which may include: S1: TS / RTP multicast to media stream encapsulation process for live streaming services: Device 1 receives the multicast streams from the encoding cluster output and the aggregation switch output (TS over RTP over UDP over IP), parses and demultiplexes the TS packets to recover the PES packets, and recovers the ES stream video NALU series and audio frame access units of the PES packets. At the same time, it extracts the metadata of each video / audio frame in the PES packets, such as PTS, DTS, frame type (I / P / B), sample size, offset, and encoding parameters PMT / SPS / PPS, index, and sample number. After sampled the video NALUs and audio frame access units and implemented CENC standard encryption, it encapsulates them into CMAF media fragments (.m4s) media files with GOP duration as the unit. At the same time, it uses the extracted sample-level metadata and DRM encryption information metadata to generate the initial fragment init.mp4, and generates the HLSm3u8h / DASHmpd manifest based on the fragment-level metadata. It also sets up the HTTP1 service channel for the media stream and the HTTP2 service channel for the manifest + initial fragment. Device 2 pulls the media fragments, manifest, and initial fragments. Device 1 samples its video NALU and audio frame access units and implements CENC standard encryption to encapsulate media files in CMAF media segments (.m4s) with GOP as the unit, along with the corresponding HLSm3u8h and DASHmpd manifests and initialization segments. Meanwhile, when Device 2 pulls media segments, it provides metadata of the start timestamp (PTS) of each media segment level in the HTTP header of each segment, and provides the media file, manifest, initialization segment, and PTS in the segment-level metadata to the platform-side media stream multicast gateway device 2.

[0055] S2: Live Streaming Service CMAF Media Segmentation to CMA / RTP Multicast Stream Encapsulation Process: Device 2 retrieves the CMAF media fragment (.m4s) file encrypted with the CENC standard from Device 1 via HTTP channel 1. Without parsing the media fragment, it obtains the start timestamp (PTS) of the fragment provided by Device 1 from the CMAF media fragment (.m4s) response header. The media fragment is treated as a black box, segmented into CMA / RTP packets using the RT FU-A standard, and encapsulated into RTP packets. The RTP header is assigned a triple identifier: timestamp (PTS), serial number, and FU-A. This encapsulates the fragment into a CMA / RTP multicast stream, achieving protocol conversion from CMAF media fragment (.m4s) to CMA / RTP multicast stream. The CMA / RTP multicast stream of the CMAF media fragment (.m4s) file is then broadcast in static multicast mode for Device 3 to receive, achieving efficient, low-latency transmission of the media fragment data stream to the access network central office. Device 2 retrieves the initialization fragment init.mp4h and HLSm3u8h / DASHmpd manifest corresponding to the media fragment through HTTP channel 2, implements proxy caching for the HLSm3u8h and DASHmpd manifests, and permanently caches and manages the version of init.mp4h, so that the streaming media gateway device 3 at the access network end can retrieve the init.mp4h and HLSm3u8h and DASHmpd manifests through the core network HTTP channel; Device 2 outputs a UDP streaming channel and an HTTP2 service channel. The UDP channel transmits media fragment multicast streams, while the HTTP2 channel transmits manifests and initial fragments. This achieves "separation of control and data," completely decoupling the low-frequency changing static metadata (manifests, initial fragments) from the high-frequency changing media streams (media fragments), thus providing a foundation for multicast encapsulation and transmission of media streams in Device 2.

[0056] S3: Core network relay transmission + HTTP channel transmission of streaming media fragmentation and metadata process: Within the core network, CMA / RTP multicast streams of CMAF media fragment (.m4s) files are transmitted using relay mode; media fragment lists and initial fragments are transmitted using the HTTP channel; "control and data separation" is achieved, completely decoupling the low-frequency changing static metadata (list, initial fragments) from the high-frequency changing media stream (media fragments). The multicast channel improves media stream transmission efficiency and reduces transmission costs, while the HTTP channel transmits static metadata (list, initial fragments), preserving the standard specifications for reliable transmission of streaming media protocols.

[0057] S4: Access network end streaming media CMA / RTP multicast to CMAF media fragment reassembly (.m4s) process: Device 3 receives the streaming media segment CMA / RTP multicast stream broadcast from the platform side and transmitted through the core network multicast relay via the multicast channel. It parses out the small blocks that each streaming media segment is cut and encapsulated into multiple RTP packet payloads on the platform side, sorts all the RTP packet payloads of each streaming media segment according to the triple mechanism of RTP packet header sequence number, timestamp and FU-A identifier, and reassembles them into continuous original streaming media segment (.m4s) files without errors, and stores them in the streaming media segment circular buffer. Device 3 retrieves the initialization segment init.mp4 file and HLSm3u8h / DASHmpd manifest corresponding to the streaming media segment from device 2 on the platform side via the HTTP channel. The initialization segment init.mp4 is cached in the permanent cache. The manifest URL of the HLSm3u8h / DASHmpd manifest is rewritten and the media segment and manifest file are synchronized and then cached in the manifest cache area. Device 3 provides HTTP service interface paths for streaming media segments (.m4s) / HLSm3u8h / DASHmpd manifest / initialization segment init.mp4 on the user side, allowing user terminals to pull the HLSm3u8h / DASHmpd manifest, initialization segment init.mp4, and streaming media segment (.m4s) files according to the path through the access network and home router.

[0058] S5: Integrated Business Aggregation and Forwarding Process: Device 4 enables the aggregation and forwarding of broadband services, communication services, video-on-demand services, live streaming media streams, and media stream listings / initial fragmentation. It provides full-service support to users through the access network and home routers. Device 4 can be configured in three modes: Mode 1: Utilize the existing BRAS in the network to implement DHCP relay; Mode 2: Reuse the existing BRAS, but move the DHCP function of the BRAS down to the integrated service gateway (to implement lightweight MSCG function). Mode 3: For newly built systems, they can be upgraded to be equipped with a cost-capacity control gateway (MSCG) based on the number of users.

[0059] S6: Access network multi-service multiplexing, cross-connection, and access procedures: For fiber-to-the-home (FTTH) scenarios, MPO high-density interface fiber optic switches can be equipped, while for copper cable FTTH environments, general-purpose Layer 2 switches can be equipped, providing gigabit or 10-gigabit interfaces to connect to home routers, enabling access to triple-play services, or existing PON networks can be utilized for access.

[0060] S7: User terminal accesses the system's access network via a home router to receive live media stream protocol services on the user side: The media stream list, initialization segments, and media stream segments can be retrieved and played through the media segment / initialization segment / media stream list paths provided by the user-side HTTP service interface of device 3. To minimize channel switching time, the system supports pre-fetching the initialization segments (init.mp4) of all channels during terminal registration and caching them locally, with version management. In the actual process, after retrieving the list for a specific program, the corresponding initialization segment (init.mp4) is compared in local memory. If a match is found, the player is directly read and initialized, and the corresponding media segment (.m4s) is retrieved for playback. This pre-fetching and local caching mechanism reduces channel switching time by 20-50ms compared to requesting the list, then requesting the initialization segment, and then requesting the media segment. The CENC standard encrypted HLS / DASH streaming media protocol live broadcast service supports reception and playback on various smart terminals such as set-top boxes + non-smart TVs, smart TVs, computers, and mobile phones, fundamentally solving the problem of insufficient compatibility of UDP multicast, IP broadcast, and DVB broadcast with home networks and smart terminals.

[0061] In one example, the TS / RTP processing flow of device 1 described above may include: After parsing and demultiplexing the TS packet and restoring the ES stream data and PTS / DTS metadata of the PES packet, it is encapsulated into CMAF media fragments and corresponding manifests and forwarded to device 2.

[0062] S1: TS / RTP to Media Fragmentation Encapsulation: S1.1: Receive the TS Over RTP Over UDP live streaming multicast stream output by the encoding cluster on the receiving platform side; S1.2: Parse and demultiplex TS / RTP packets, restore PES packets to the video NALU series and audio frame access units of the ES stream, and encrypt and encapsulate media fragments after sampled access units; S2: Sample-level metadata generation: S2-1: Sample-level metadata generation. The PES packet parsing module parses the PES packet to extract the PTS / DTS, frame type (I / P / B), sample size, and offset of each video / audio frame to generate sample-level metadata for constructing the segment trun / tftd box. It only exists during the encapsulation of this segment and is cleared after encapsulation is completed. S2-2: Encoding parameter generation. The PES packet parsing module parses the PES packet and extracts the encoding parameters PMT / SPS / PPS. S2.3: DRM encryption metadata generation. After encrypting the media segment samples, the Moof part is generated, which includes the segment encryption flag, encryption byte range, and sample encryption information, and the moov part includes metadata such as KID, PSSH, IV, encryption range, and encryption flag. S3: Initialize fragment generation, read the moov part of the encoding parameters and DRM encryption information metadata: KID, PSSH, IV, encryption range, encryption flag, and generate the initial fragment init.mp4; S4: Fragment-level metadata generation. Extract the fragment start frame (PTS), fragment duration, and fragment sequence number from the sample metadata. Then add the fragment URL, DRM type, license URL, KID, file size, and the version number and URL of the initial fragment to generate fragment-level metadata and store it in the fragment-level metadata cache.

[0063] S5: The list generation process reads the media segment metadata and generates a media segment list; S6: HTTP service process. Based on the request from device 2, the initial fragment, media fragment list and media fragments are returned to device 2. In the HTTP header of the returned media fragments, the fragment-level metadata start frame PTS is added, and the initial fragment and media fragments are transmitted in the "out-of-band metadata + black box transmission" mode.

[0064] In one example, the initial fragmentation, manifest, and media fragmentation processing flow for device 2 may include: S1: Device 2 Inventory Processing Module (HTTP Service): S1.1: Retrieve the original list from upstream: Protocol: HTTP / 1.1 or HTTP / 2, using persistent connections (Keep-Alive) to reduce handshake overhead.

[0065] Pull method: For each channel, periodically (e.g., every 2 seconds) request the latest manifest file (.m3u8 or .mpd) from the upstream source.

[0066] Caching strategy: Store the retrieved original manifest in memory cache and mark it with the retrieval timestamp and version number.

[0067] S1.2: Inventory caching and proxy services: Device 2 internally starts a lightweight HTTP server (such as Nginx) and exposes an inventory pull interface for device 3 to call.

[0068] Interface example: http: / / [Device2-IP] / manifest / channel_1.m3u8 http: / / [Device2-IP] / manifest / channel_1.mpd Response header optimization: Add Cache-Control: max-age=1, allowing device 3 to cache for 1 second, but requiring revalidation (must-revalidate) to ensure that device 3 can obtain the latest inventory in a timely manner.

[0069] S1.3: Optional list enhancements (assisted synchronization): Device 2 can add custom tags to the original manifest, helping Device 3 achieve precise synchronization between media and the manifest. For example: m3u8 #EXT-X-MULTICAST:GROUP=239.1.1.1:5000,SSRC=12345 #EXT-X-RTP-MAP:SEGMENT=12345,TIMESTAMP=90000; These labels indicate information such as the multicast address, SSRC, and start RTP timestamp of the corresponding media segment in the CMA / RTP multicast stream.

[0070] S2: Device 2 Media Processing Module (RTP Multicast Transmission): S2.1: Obtain CMAF fragments: Device 2 pulls or receives CMAF media fragment (.m4s) files pushed from upstream. Each fragment corresponds to a program of fixed duration (e.g., 2 seconds). This duration is the GOP length of each fragment, which is also the length of time that the content in each fragment can be played in the player. The HTTP response header pulled carries the metadata of the fragment, including X-Fragment-Timestamp.

[0071] S2.2: Treat CMAF fragments as binary black boxes: It does not parse the ISOBMFF structure inside the fragment, does not decrypt, does not modify the content, and only reads the binary data of the entire fragment.

[0072] S2.3: RTP FU-A fragmentation and encapsulation of CMA / RTP packets: For each CMAF fragment, perform RTP encapsulation as follows: Determine the RTP payload size: Subtract the IP header (20), UDP header (8), and RTP header (12) from the network MTU (e.g., 1500 bytes) to reserve a safety margin, usually set to 1360 bytes.

[0073] Fragmentation: The CMAF fragmented binary data is divided into multiple blocks (RTP payload), each block being no larger than 1360 bytes.

[0074] Add FU-A header: Add FU indicator bytes and FU header bytes to each RTP packet.

[0075] The first packet: The FU header is set to S=1 (start of fragmentation) and E=0.

[0076] Intermediate package: S=0, E=0. Regardless of the number of intermediate packages, all of them have S=0 and E=0.

[0077] Last packet: S=0, E=1 (end of fragmentation).

[0078] Fill the RTP header: Sequence number: Each RTP packet is assigned an incrementing 16-bit sequence number (independent for each program).

[0079] Timestamp: All RTP packets of the same CMAF fragment use the same RTP timestamp, which is either provided by the upstream and is the X-Fragment-Timestamp of the fragment, or obtained by parsing the tfdt of the fragment header.

[0080] SSRC: Each program uses a fixed 32-bit synchronization source identifier.

[0081] S2.4: Multicast transmission: Encapsulate UDP / IP: Add UDP and IP headers, and set the destination address to a pre-allocated static multicast address (e.g., 239.1.1.1:5000).

[0082] Using two 25G network cards, the encapsulated RTP / UDP packets are sent to the network via static multicast.

[0083] Static multicast indicates that the IGMP protocol is not enabled. The network device forwards data packets to the multicast stream receiving ports of all devices 3 through a pre-configured relay channel. Device 3 listens for all program UDP multicast streams broadcast on the receiving platform side in promiscuous mode.

[0084] S3: Initialize shard fetching and caching: Device 2 pulls the initial shards from the device via the HTTP channel and uses tool caching (permanent cache within the version) for version management so that device 3 can pull the initial shards via the HTTP channel.

[0085] Device 3, the data processing process may include: S1. Manifest Processing Module (HTTP Client + Manifest Rewriting): S1.1: Retrieve list: Device 3 periodically (e.g., every 2 seconds) sends an HTTP GET request to the inventory service interface of Device 2 via the 10G interface.

[0086] Optimization measures: Use persistent HTTP connections (Keep-Alive) to avoid frequent TCP handshakes.

[0087] Enable TCP Fast Open (TFO) to further reduce latency.

[0088] Binding the list retrieval process to a dedicated CPU core ensures processing stability.

[0089] S1.2: Parse the original list: After receiving the list returned by device 2, device 3 parses its contents to obtain: fragment sequence number (EXT-X-MEDIA-SEQUENCE); duration of each fragment (EXTINF); original fragment URL; DRM information (EXT-X-KEY, including license URL and KEYFORMAT); and any custom multicast mapping tags that may exist (such as EXT-X-MULTICAST).

[0090] S1.3: Rewrite the manifest (localization): Device 3 generates a new manifest file for the terminal to request. The rewrite rules are as follows: Fragment URL Replacement: Replace the original fragment URL (pointing to device 2 or upstream) with the local HTTP address of device 3.

[0091] Original source: https: / / cdn-origin.com / ch1 / seg_12345.m4s

[0092] Rewrite: http: / / [Device3-IP] / cache / ch1 / seg_12345.m4s

[0093] DRM information remains unchanged: the EXT-X-KEY label is retained as is, ensuring that the terminal still requests authorization from the original DRM license server.

[0094] Add synchronization information (optional): Custom tags can be added to the manifest to indicate the RTP multicast stream information corresponding to each segment, which is convenient for internal debugging.

[0095] The rewritten list is stored in the memory or SSD cache of device 3, with a very short cache expiration time (e.g., 1 second).

[0096] S2: Media Reception and Reassembly Module (Receiver 2 cuts and encapsulates media fragments using FU-A and outputs CMA / RTP multicast streams): S2.1: No need to join a multicast group: Device 3's 25G network card is configured to listen to all preset static multicast addresses in promiscuous mode (each program corresponds to an independent multicast IP and port). Because it is static multicast, there is no need to send IGMP join messages; the network card directly receives data packets destined for these multicast addresses.

[0097] S2.2: RTP packet reception and preliminary processing: Each program's RTP multicast stream is processed by an independent receive thread / coroutine, and different streams are bound to different CPU cores via RSS (Receiver Scaling).

[0098] For each received RTP packet, extract the following information: sequence number (for sorting and packet loss detection), timestamp (for synchronization), and S / E flag in the FU-A header (for determining fragmentation boundaries).

[0099] S2.3: Packet Loss Detection and Recovery Serial number continuity check: If a serial number jump is detected, it is considered that a packet loss has occurred.

[0100] FEC Decoding: If forward error correction is enabled (e.g., add 1 FEC packet for every 10 media packets), try to recover the lost packets using FEC.

[0101] Retransmission request: If FEC cannot recover, request device 2 to retransmit the missing RTP packets through the backup TCP channel (device 2 must support retransmission function).

[0102] Silent discard: If a retransmission times out (e.g., 50ms), the fragment is discarded and the system waits for the next complete fragment (applicable to non-key frames).

[0103] S2.4: RTP reassembled into a complete CMAF fragment: For each program's RTP stream, maintain a reassembly buffer.

[0104] When the start of a FU-A fragment is detected (S=1), a new buffer is created, and subsequent received RTP packet payloads (excluding RTP and FU-A headers) are appended sequentially until the end packet (E=1) is received. The reassembly rules are as follows: S=1 for the FU-A identifier indicates the start of a media fragment; RTP payloads with the same timestamp belong to the same media fragment; the sequence number determines the order of each TRP payload within that media fragment; E=1 represents the last RTP payload of that media fragment, where the sequence number increments across media fragments, thus also determining the media fragment order. After reassembly, the resulting data is the complete binary content of the original CMAF media fragment (.m4s) file.

[0105] S2.5: Media Fragment Storage and Indexing: Write the reassembled complete CMAF fragment to memory or SSD cache. It is recommended that the file name format include the channel ID, timestamp, or sequence number, for example: / cache / ch1 / seg_12345.m4s.

[0106] At the same time, update the memory index table to record information such as the URL path, file size, and expiration time corresponding to the shard.

[0107] S3: HTTP service module of device 3 (providing services to the terminal): S3.1: Start the HTTP server: Device 3 starts a high-performance HTTP server (such as Nginx or Caddy) on the 100G interface to listen for terminal requests.

[0108] S3.2: Process terminal list requests: Terminal request: http: / / [Device3-IP] / hls / ch1.m3u8.

[0109] Device 3 reads the latest rewritten list of the channel from the memory cache and returns it directly to the terminal.

[0110] Set appropriate caching controls in the response header (e.g., Cache-Control: max-age=1) to ensure that the terminal can obtain updates in a timely manner.

[0111] S3.3: Handling terminal media fragmentation requests: The terminal requests the specific fragment file based on the URL in the list, such as http: / / [device3-IP] / cache / ch1 / seg_12345.m4s.

[0112] Device 3 searches for the file in memory or SSD cache: If it exists, use sendfile zero-copy technology to send the file content directly.

[0113] If it does not exist (in very rare cases, such as a cache miss), it can be retrieved from device 2 or upstream, but this situation should be avoided as much as possible.

[0114] S3.4: Cache Expiration Management A sliding window strategy is used to cache the most recent 60 seconds of file segments (equivalent to 30 segments of 2 seconds each).

[0115] Regularly clean up expired files to free up cache space.

[0116] S3.5: Initialize fragmentation: Initial fragments can be pre-fetched, meaning that each channel's initial fragment is cached locally as soon as the device boots up, so that the terminal device can pre-fetch the initial fragments.

[0117] The synchronization mechanism between the playlist and media segments requires that, during playback on the terminal, the acquired playlist and the reconstructed media segments be aligned in time. For example, the Nth segment listed in the playlist must be the segment that device 3 has just reconstructed from the multicast stream.

[0118] Synchronization strategy, timestamp alignment: When sending RTP streams, device 2 sets the same RTP timestamp for each CMAF fragment, which is proportional to the fragment's PTS (display timestamp).

[0119] After reassembling the fragments, device 3 can record the RTP timestamp of the fragment and establish a mapping with the time information in the list (e.g., EXT-X-PROGRAM-DATE-TIME).

[0120] Serial number alignment: The EXT-X-MEDIA-SEQUENCE in the manifest indicates the current fragment sequence number.

[0121] Device 2 can send this serial number via RTP extension header or a custom method along with the stream, and Device 3 verifies the consistency of the serial number during reassembly.

[0122] Synchronous fault tolerance: If device 3 finds that a fragment in the list is not present in its local cache (possibly due to RTP packet loss or latency), it should: a. Wait for at most one fragment duration (e.g., 2 seconds) to see if it can be recovered from subsequent RTP packets.

[0123] b. If a timeout occurs, retrieve the fragment from device 2 via HTTP origin server as a backup.

[0124] c. Skip this segment in the playlist (requires EXT-X-DISCONTINUITY support) to avoid playback interruption.

[0125] First frame fast start: Device 3 pre-caches at least one fragment for each channel and immediately returns the prepared fragment URL when the terminal requests the list, ensuring the first frame time is ≤ 500ms.

[0126] The transmission content, protocol, direction, and key operations for different channels are shown in Table 1 below: Table 1

[0127] The main functions of device 1 include: TS / RTP to CMAF Media Fragmentation and Encapsulation: For live streaming services that receive TS / RTP multicast streams, parse and demultiplex the TS packets, restore the video NALUs and audio frames, and encapsulate them into CMAF media fragments using sample encryption. Generate media segment manifest file: Extract segment-level metadata, generate segment-level metadata and generate a media file manifest; Generate initial fragments: Read the encoding parameters and fragment-level DRM encryption metadata to generate initial fragments; Provide device 2 with the start timestamp of fragment-level metadata: extract the fragment start PTS from the fragment-level metadata and provide the start PTS in the fragment return header.

[0128] The main functions of device 2 include: Inventory and Initialized Shard Agent: Maintains synchronization with upstream inventory and initialized shards, providing a reliable inventory and initialized shard pull interface for device 3.

[0129] Media fragmentation: CMAF fragments are cut into CMA / RTP packet fragments according to the RTP / FU-A standard, and then encapsulated into CMA / RTP UDP multicast streams. The CMA / RTP UDP multicast streams are then multicast through the user-side UDP interface in flood mode.

[0130] The main functions of device 3 include: List processing: The list is pulled from device 2, parsed and rewritten, and then cached in the list cache after being synchronized with the media segments so that the user can pull it.

[0131] Initialize fragment retrieval: Retrieve initial fragments from device 2 and cache them, manage versions, and retrieve them from multiple terminals.

[0132] Media fragment reassembly: The CMA / RTP multicast stream broadcast by promiscuous mode receiving device 2 is parsed to extract RTP / FU-A standard fragments, reassembled into CMAF media fragments, and buffered.

[0133] HTTP Service: Provides initialization segments, manifests, and CMAF media segment (.m4s) files to mobile phones, computers, and smart TVs using standard HTTP.

[0134] In other words, it features native HLS / DASH unicast, requiring no terminal customization and fully compatible with various smart terminals. The core network transmits only one multicast stream, making the access network a dedicated HLS / DASH live streaming platform. Compared to full CDN transmission of HLS / DASH files, it significantly reduces CDN and bandwidth investment. CMA / RTP direct transmission and static multicast ensure end-to-end latency is controlled within 500ms. Dual-channel separation ensures that media stream flow is unaffected by list loss, and media fragment loss is protected by FEC and retransmission protection (optional).

[0135] During implementation, the system business processing flow can be as follows: Figure 2 As shown, the entire process can be divided into three stages: Stage 1: Content preparation is complete; Stage 2: Terminal registration and verification to obtain a token; Stage 3: The terminal presents the token to request content and obtains a license to decrypt and play it. Among these: Phase 1 may include Figure 2 Processes 1 to 15 in the process: Process 1: Device 1 receives each program's TS / RTP multicast stream from the encoding cluster in static multicast mode and parses out the video NALU and audio frames in order to achieve CENC standard encryption of the video frame NALU and audio frame samples of each program. Procedure 2: Device 1 obtains the encryption key CK and key identifier KID from the DRM key server; Process 3: The key server generates a unique encryption key CK and key identifier KID for each program; Step 4: The key server returns the encryption key CK and key identifier KID requested by device 1; Step 5: Save the encryption key CK and key identifier KID; Step 6: Push and store the encryption key CK and key identifier KID in secure mode to the license server; Step 7: The license server securely stores the encryption key CK and key identifier KID so that the DRM client can obtain the decryption key CK; Process 8: Device 1 performs encrypted encapsulation of CMAF media fragments (.m4s) and generates an HLSm3u8h / DASHmpd manifest and initializes the fragment init.mp4; Process 9: Device 2 pulls the encrypted CMAF media segment (.m4s) file, HLSm3u8h / DASHmpd manifest, and initialization segment init.mp4, and carries the start timestamp (PTS) of the media segment in the segment HTTP header; Process 10: Device 2 implements RTP / UF-A binary fragmentation of encrypted CMAF media fragments and encapsulates them into CMA / RTP multicast streams; Process 11: Device 2 proxies the list and initializes the fragment init.mp4, providing Device 3 with a pull interface and a synchronization identifier for the list and fragments (corresponding to the fragment multicast address). Process 12: Device 3 pulls the HLSm3u8h / DASHmpd list of CMAF media fragment (.m4s) files and the fragment initialization init.mp4 from Device 2; Process 13: Device 3 rewrites the media file URL in the manifest, with the URL pointing to Device 3 itself, retaining encrypted information, to achieve synchronization between the reassembled fragments and the rewritten manifest. At the same time, it pulls the initial fragment init.mp4 and caches the rewritten manifest and the pulled initial fragment so that it can be pulled by the user. Procedure 14: Device 2 outputs a static multicast CMA / RTP multicast stream to multiple devices 3 for reception; Process 15: Each device 3 receives the CMA / RTP multicast stream, parses out the FU-A fragments, reassembles the original CMAF media fragments, and pulls the HLSm3u8h / DASHmpd list and initializes the fragment init.mp4; Phase 2 may include Figure 2 Processes 16 to 25: Step 16: The terminal powers on, logs into the authentication gateway, submits its identity credentials for verification, and receives a token; Process 17: The authentication gateway verifies the user's identity credentials. If the verification result is not saved, it submits it to the user management system for verification. Process 18: The authentication gateway submits a user identity credential verification request to the user management system; Process 19: The user management system verifies the user's identity credentials (including purchase of business permissions). Process 20: The user management system returns the user authentication result; Step 21: The authentication gateway saves the verification result; Process 22: The authentication gateway provides the user with a content request token based on the verification result; Step 23: The authentication gateway generates the user token public key; Process 24: The authentication gateway pushes the public key to device 3; Process 25: Device 3 obtains and saves the token verification public key provided by the authentication gateway in order to verify the token of the requested service; Phase 3 may include Figure 2 Processes 26 to 40 in the middle: Process 26: The user presents a token to device 3, requests a list of programs to be watched, and initializes the segment init.mp4; Procedure 27: Device 3 uses the public key provided by the authentication gateway to verify the validity of the user token; Process 28: If the verification is successful, return the fragment list HLSm3u8h / DASHmpd requested by the user and the fragment initialization init.mp4; Process 29: The user requests the corresponding CMAF media segment (.m4s) file from device 3 using the media segment URL in the list; Process 30: Device 3 verifies the user token. If the verification is valid, it provides the requested CMAF media fragment (.m4s) file. Process 31: The user obtains the requested CMAF media fragment (.m4s) file; Process 32: If the media segment obtained by the user is unencrypted, it will be played directly; if it is encrypted, the user will request a decryption key from the license server. After the license is approved, the user will obtain the CK and decrypt the encrypted content to play. Step 33: If the terminal detects that the content is encrypted, it will present the KID and request the decryption key CK according to the manifest and the key URL given in the initialization fragment init.mp4; Process 34: The license server verifies user permissions. If no saved information is found, it verifies user permissions with the user management system. Process 35: The license server submits user identity credentials to the user management system for verification; Process 36: The user management system verifies the user identity submitted by the license server; Process 37: The user management system returns the verification result to the license server; Step 38: The license server provides the corresponding decryption key CK based on the KID presented by the terminal; Step 39: The terminal obtains the CK provided by the license server using a secure encryption method, and completes decryption and playback; Process 40: The terminal repeatedly requests to play the content within the token verification validity period until viewing is stopped or the terminal logs in again upon startup.

[0136] In one embodiment, Figure 3 The diagram shows a functional module of the TS / RTP multicast stream to reassemble CMAF media fragment (.M4s) media stream encapsulation gateway (device 1 data layer) provided in this application.

[0137] The data layer of device 1 mainly consists of the TS / RTP multicast stream receiving interface 0401, the TS / RTP packet receiving engine 0402, the device 1 buffer management module 0403, the TS demultiplexing and PES packet reassembly module 0404, the PES packet parsing module 0405, the encryption key retrieval interface 0406, the CENC standard encryption module 0407, the CMAF fragment encapsulation module 0408, the media file writing module 0409, the initialization fragment encapsulation module 0410, the manifest generation module 0411, the HTTP service module 1 0412, the media fragment file output interface 0413, the HTTP service module 2 0414, and the manifest output interface 0415.

[0138] The device 1 cache management module 0403 may include: TS packet ring cache 0403-1, PES packet cache 0403-2, clear stream sample cache 0403-3, encrypted sample cache 0403-4, PES packet sample-level metadata cache 0403-5, encoding parameter cache 0403-6, media fragment (.m4s) temporary cache 0403-7, CMAF media fragment (.m4s) publishing cache 0403-8, fragment-level metadata cache 0403-9, initial fragment .mp4 publishing permanent cache 0403-10, HLSm3u8h and DASHmpd manifest cache 0403-11, and DRM encrypted information metadata cache 0403-12, so as to provide caching and reading for related modules during data processing.

[0139] Device 1's data layer receives the encoding and compression of each live program from the live streaming service platform's encoding cluster, which is then aggregated by the aggregation switch and broadcast via static multicast (TS over RTP over UDP over). After the IP multicast stream is processed, the TS packets are parsed and demultiplexed to restore the video NALU series, audio frame access units, and metadata. After sampled access units and CENC encryption of the sample payload, CMAF media fragment (.m4s) files, corresponding HLSm3u8h / DASHmpd manifests, and fragment cache initialization are encapsulated in closed GOPs of a certain duration. Media fragment interfaces, manifest interfaces, and fragment initialization interfaces are provided for device 2 to pull CMAF media fragment (.m4s) files, corresponding HLSm3u8h / DASHmpd manifests, and fragment initialization. At the same time, the display timestamp (PTS) of the start frame (IDR frame) of the media fragment is provided in the return header of the fragment file pulled by device 2, so that device 2 can obtain the start timestamp of the fragment without parsing the media fragment. When a media fragment is cut into multiple RTP packets, the media fragment PTS is used to mark all RTP packets after the media fragment is cut, ensuring that all RTP packets marked with the same PTS belong to the same CMAF media fragment.

[0140] In one example, a data processing flow is provided for a TS / RTP multicast stream to a reassembled CMAF media fragment (.M4s) media stream encapsulation gateway (device 1), which may include: S1: RTP receiving engine 0402: Receives TS Over RTP Over UDP Over IP multicast streams encoded and compressed by the live streaming platform's encoding cluster and broadcast by the aggregation switch via TS / RTP multicast stream receiving interface 0401. After parsing the RTP packets, it stores them in the TS packet ring buffer 0403-1 of the device 1 buffer management module 0403. Each channel is indexed by channel ID and 200 RTP packets are cached, with a timeout of 200ms.

[0141] S2: TS demultiplexing PES stream reassembly module 0404: Reads RTP packets from TS packet ring buffer 0403-1, extracts TS packets, demultiplexes TS packets to restore video and audio PES streams, and stores them in the PES packet buffer 0403-2 of device 1 buffer management module 0403 according to PID. The buffer capacity for each channel is 64KB, and the timeout is 200ms.

[0142] S3: PES parsing module 0405: Reads PES packets from PES packet buffer 0403-2, parses out the video NALU series and audio frames of the ES stream, as well as PES packet metadata PTS / DTS and encoding parameters PMT / SPS / PPS, stores the unencrypted video NALU series and audio frames in GOP units into the clear stream sample buffer 0403-3 (dual buffer mode) of device 1 buffer management module 0403; stores the PES packet metadata (PTS, DTS, frame type (I / P / B), sample size, offset of each video / audio frame) into the PES packet sample metadata buffer 0403-5 of device 1 buffer management module 0403; stores the encoding parameters PMT / SPS / PPS into the encoding parameter buffer 0403 of device 1 buffer management module 0403.

[0143] S4: CENC standard encryption module 0407: Reads the clear stream video NALU series and audio frames from the clear stream sample buffer 0403-3, obtains the encryption key CK from the key server through the encryption key retrieval interface 0406, samples the video NALU series and audio frames, and implements CENC standard encryption. The encrypted samples are then cached in the encrypted sample buffer 0403-4 (dual-buffering mode) of the device 1 buffer management module 0403, caching one GOP. Simultaneously, DRM encryption information metadata: fragment encryption flag, encryption byte range, sample encryption information; KID, PSSH, IV, encryption range, and encryption flag are written to the DRM encryption information metadata buffer 0403-12.

[0144] S5: CMAF Fragmentation and Encapsulation Module 0408: Reads encrypted video NALU series and audio frame samples from the encrypted sample buffer 0403-4, and simultaneously reads the video NALU series and audio frame sample metadata from the PES packet sample metadata buffer 0403-5 and the encrypted information moof part from the DRM encryption information metadata buffer 0403-12. 1. Construct moof +mdat → seg_ 1. Encapsulate the metadata into moof, encapsulate the encrypted video NALU series and audio frames into mdat, generate CMAF media fragments (.m4s) and store them in the media fragment (.m4s) temporary buffer 0403-7; 2. Extract the metadata of the CMAF fragment (starting PTS, duration (ms), sequence number, file size and DRM information) and write the data to the fragment-level metadata buffer 0403-9.

[0145] S6: Media file writing module 0409: Reads CMAF media segment (.m4s) files from media segment (.m4s) temporary buffer 0403-7 and writes them to CMAF media segment (.m4s) publishing buffer 0403-8 for HTTP service module 1 to read.

[0146] S7: Initialization Segment Encapsulation Module 0410: Reads encoding parameters PMT / SPS / PPS from encoding parameter cache 0403-6, and reads the encrypted information moov part from DRM encrypted information metadata cache 0403-12. 1. Builds ftpy + moov → init.mp4, generating: complete initialization segments stored in initialization segment.mp4 and permanently cached in the permanent cache 0403-10, and is responsible for version updates and overwriting. The initialization segment carries the (ftyp box) file type and compatibility declaration as well as the (moov box) global metadata and decoding instructions. For each program, the initialization segment is only output once each time it starts, but the version is updated and overwritten again when the encoding parameters change (e.g., #EXT-X-MAP:URI="init_vN.mp4"), where N is the version number, so that devices 2 and 3 can pull the new version of the initialization segment. 2. Extract the metadata of the initialization segments, such as the init_version (e.g., v2) and init_url (e.g., init_v2.mp4) fields, and write them to the segment-level metadata cache 0403-9. The metadata of the initialization segments can also be cached independently to separate it from the segment-level metadata generated frequently every 2 seconds by the media segment encapsulation module and the metadata generated less frequently by version for the initialization segments. The manifest generation module reads the segment-level metadata and the initialization segment metadata respectively to generate the media segment manifest file.

[0147] S8: Media File Manifest Generation Module 0411: Reads media segment metadata and initialization segment metadata from segment-level metadata cache 0403-9, generates m3u8h and mpd manifests for CMAF media segment (.m4s) files, and stores them in HLSm3u8h and DASHmpd manifest cache 0403-11. The manifests contain: channel ID, initialization segment metadata (#EXT-X-MAP:URI="init_v{N}.mp4"+initialization="init_v{N}.mp4", initialization segment version number (e.g., v2), initialization segment URL (e.g., init_v2.mp4), and media segment metadata including media segment sequence number, starting PTS, segment duration, segment URL (e.g., seg_12345.m4s), etc. Encrypted DRM information is contained within the initialization segment.

[0148] S9: HTTP Service Module 1: Based on the media data retrieval mechanism of Device 2, it reads media segments from the CMAF media segment (.m4s) publishing cache 0403-8 and the media segment start timestamp (PTS) from the segment-level metadata cache 0403-9. After writing the PTS into the media segment response header, it forwards it to the media segment retrieval module of Device 2, thus realizing the forwarding of media segments and timestamps. The media segment response body is for each segment. The purpose of writing the start timestamp (PTS) into the response header is to allow Device 2 to obtain the start PTS of the segment without parsing it, which is used to tag all RTP packets of the same segment that are divided into multiple RTP packets with a unified label. HTTP service module 2: Based on the media manifest and initial fragment retrieval mechanism of device 2, it reads the HLSm3u8h and DASHmpd manifests from the manifest cache area 0403-11 and forwards them to the manifest retrieval module of device 2 to realize manifest forwarding; at the same time, based on the initial fragment retrieval requirements of device 2, it reads the initial fragment from the initial fragment .mp4 publishing permanent cache area 0403-10 and forwards it to device 2. Device 1 is equipped with HTTP1 and HTTP2 service modules. The purpose is that channel 1 transmits media fragments, focusing on high-frequency media streams, maintaining simple black-box processing and efficient transmission; channel 2 (HTTP) carries low-frequency static metadata, which can be cached and proxied. This separation significantly reduces system complexity. Achieving "control and data separation" completely decouples the low-frequency changing static metadata (manifest, fragment initialization) from the high-frequency changing media streams (media fragments), greatly simplifying system complexity and improving transmission efficiency.

[0149] Device 1 implements the above process: How the CMAF wrapper recovers PES packets from the TS stream: Synchronize TS stream: Found 0x47 synchronization byte.

[0150] Parse the TS packet with PAT:PID=0 to obtain the PID of PMT.

[0151] Parse PMT: Obtain the video PID and audio PID.

[0152] Filter TS packets: Only keep TS packets containing the video PID and audio PID.

[0153] Extracting the payload: After removing the header from each TS packet, slices of the PES packet are obtained.

[0154] Reassemble PES packets: The start of a PES packet is identified by the payload_unit_start_indicator flag. Continuous TS payloads with the same PID are spliced ​​together to obtain a complete PES packet.

[0155] Parse the PES header: extract PTS / DTS, stream_id, and payload (i.e., ES data: video NALU or audio frame).

[0156] Processing in CMAF wrappers: In the CMAF encapsulator, after recovering the video and audio ES data, the following processing is performed: Video Samples: Each video access unit (the complete NALU sequence obtained from the PES payload) is treated as a video sample. The PTS / DTS in the PES header is converted into a timestamp for the CMAF sample (written to the trun). Audio Samples: Each audio access unit is treated as an audio sample. The PTS is written to the CMAF fragment. Media Fragment Encapsulation: Multiple video and audio samples are written to the same .m4s file in a time-interleaved manner, but distinguished by different track IDs. The final file internal structure may include: moof (movie fragment box) - traf (track fragment for video) - tfhd, trun (record video samples) - traf (track fragment for audio) - tfhd, trun (record audio samples) mdat (media data) - Video sample data block - Audio sample data block.

[0157] In one embodiment, device 1 generates three products: 1) The first one is CMAF media segment moof+mdat: The moof box encapsulates two parts of metadata. One part is sample-level metadata provided by the PES packet parsing module, such as PTS (display timestamp), DTS (decoding timestamp), frame type (I / P / B), sample size, and offset. The other part is DRM encryption metadata provided by the encryption module, such as IV (initialization vector) and encryption range (in senc or saiz / saio). The mdat box encapsulates a series of video NALUs and audio frame samples for a GOP duration encrypted according to the CENC standard. Within a GOP duration, it can encapsulate multiple I, P, and B frame video NALUs and audio frame samples starting with an IDR frame.

[0158] 2) The second step is to initialize the sharding using ftyp+moov: The moof box also encapsulates two parts of sample-level metadata. One part is the sample-level metadata such as PMT, SPS, and PPS for each channel encoding parameter provided by the PES packet parsing module. The other part is the DRM encryption metadata such as KID, PSSH, IV, encryption range, and encryption flag for each sample provided by the encryption module.

[0159] 3) The third is the manifest file HLSm3u8h / DASHmpd: The manifest generation module reads the segment-level metadata cached in the segment-level metadata cache by the media segment encapsulation module and the initialization segment encapsulation module, and generates the manifest file HLSm3u8h / DASHmpd corresponding to the media segment. The segment-level metadata includes segment sequence number, start frame PTS, segment duration, segment URL, DRM type, license positive URL, and KID; the initialization segment metadata includes segment version init_v2.mp4 and path init_url.

[0160] In one embodiment, device 1 is designed with a three-layer architecture of data layer, control layer, and management layer. The functional modules of each layer are implemented according to the functions and hardware support in Tables 2, 3, 4, and 5 below. Table 2 is the data layer of device 1, which is responsible for high-speed data reception, protocol parsing, and format conversion. Table 3 is the control layer of device 1, which is responsible for stream management, synchronization, scheduling, encryption key management, etc. Table 4 is the management layer of device 1, which is responsible for configuration, monitoring, logging, and external interfaces. Table 5 is a hardware resource configuration suggestion for device 1 (medium scale, supporting 198 channels).

[0161] Table 2

[0162] Table 3

[0163] Table 4

[0164] Table 5

[0165] In one example, a schematic diagram of the data layer functional modules of the media stream multicast gateway 0108 (device 2) on the system platform side is shown below. Figure 4As shown, the data layer includes: a 100G HTTP interface 1 0601 (i.e., the CMAF media fragment (.m4s) receiving interface), a CMAF media fragment (.m4s) retrieval module 0602, a cache management module 0603, a CMA / RTP packet encapsulation module 0604 (used to read CMAF fragments to implement RTP FU-A binary segmentation, inject timestamps, sequence numbers, FU-A identifiers, and encapsulate them into CMA / RTP packets), a CMA / RTP multicast stream encapsulation static multicast module 0605, and a multicast stream output interface 0606, 2 The system includes a 10G HTTP interface (20607), an initialization fragmentation and manifest retrieval module (0608), an HTTP service module (0609), and a manifest and init.mp4 output interface (0610). The cache management module (0603) may include: a CMAF fragmentation memory ring cache (0603-1), a fragmentation start-up PTS cache (0603-2), a CMA / RTP packet output queue cache (0603-3), a manifest cache (0603-4), and an initialization fragmentation permanent cache (0603-5). This permanent cache is retrieved only once per program's initialization fragmentation during startup or appliance operation, but is retrieved again upon version update. This provides data caching and retrieval for related modules during data processing.

[0166] Device 2's data processing layer mainly consists of a CMAF media fragment (.m4s) file data processing channel, a cache management module, and a manifest and initial fragment processing channel.

[0167] In one embodiment, the data processing flow of the media stream multicast gateway (device 2) may include: S1: CMAF Media Segment (.m4s) Pull Module: Pulls CMAF segment (.m4s) files provided by device 1 through the 100G HTTP interface 1 long connection mode of HTTP channel 1, and stores them in the CMAF segment memory ring cache 0603-1 according to the channel ID and media segment sequence number. At the same time, after extracting the timestamp PTS of the first IDR frame of each CMAF segment from the HTTP header, it stores it in the segment start PTS cache 0603-2 according to the channel ID and segment sequence number.

[0168] S2: CMA / RTP Packet Encapsulation Module: Reads a complete CMAF media segment from the segmentation buffer, treats the media segment as a black box to implement RTP FU-A binary segmentation, divides each media segment into multiple RTP packet payloads, and encapsulates them into RTP packets. Reads the timestamp PTS of the first IDR frame of the segment from the PTS buffer, injects a triple identifier of timestamp, sequence number, and FU-A identifier into the RTP packet header, ensuring that the timestamp of each media segment RTP packet is the same, the sequence number is incremented, and the FU-A identifier determines the start and end of the segment RTP packet, thus completing the CMA / RTP packet encapsulation, and stores it in the CMA / RTP packet output queue buffer 0603-3 according to the channel ID and CMA / RTP packet sequence number as indexes.

[0169] S3: CMA / RTP multicast stream encapsulation static multicast module: CMA / RTP packets are read from the CMA / RTP packet output queue buffer 0603-3, encapsulated into a CMA / RTP Over UDP Over IP multicast stream, and broadcast in static multicast flood mode for device 3 to listen for and receive in promiscuous mode.

[0170] Multicast address planning: The encapsulated multicast stream is broadcast as a static multicast IP broadcast (IGMP protocol not enabled), and received by the receiver in promiscuous mode. However, since it is a private network transmission, a multicast address can be selected instead of a broadcast address.

[0171] Taking the transmission of 198 live channels as an example, since the system is a private network system from the platform side to the access network office, the multicast address can be the same IP address but different port number, or different IP address but the same port number, such as: 239.1.1.1---239.1.1.198, and the port can be fixed at 6000.

[0172] S4: Initialize the sharding and list retrieval module: via HTTP channel 2 10GHTTP interface 2 0607 pulls the m3u8h / mpd list provided by device 1, stores it in the list cache 0603-4, proxies it and makes it available for device 3 to pull; it pulls the initial fragments provided by device 1 and stores them in the initial fragment permanent cache area 0603-5, and implements version management, actively pulling new versions to overwrite old versions.

[0173] S5: M3u8h / mpd manifest + initialization of fragmented HTTP service module init.mp4: Based on the M3u8h / mpd manifest of device 3 and the HTTP service request path of the initial fragment init.mp4, the manifest file is read from the manifest cache 0603-4, and the M3u8h / mpd manifest of each channel CMAF fragment (.m4s) file is relayed to device 3; the initial fragment init.mp4 is read from the initial fragment init.mp4 cache for device 3 to pull.

[0174] The specific measures to implement the above process are as follows: Assuming there are 198 live programs, the CMAF media segment (.m4s) retrieval module 0602 establishes 198 HTTP long connections in parallel to retrieve the CMAF media segment (.m4s) from the upstream device 1. It supports HTTP / 2 multiplexing to avoid port exhaustion, receives data with zero copy, and directly writes it to the CMAF media segment (.m4s) cache area 0603-1 of the cache management module 0603 so that it can be read by the CMA / RTP packet encapsulation module 0604.

[0175] Device 2, when retrieving CMAF media fragment (.m4s) files for each live program from upstream and splitting these files into multiple CMA / RTP packets, does not parse the CMAF media fragment (.m4s) files. Instead, it treats the media fragments as binary black-box data blocks and processes them according to RTP. When the FU-A protocol is segmented into CMA / RTP packet payloads and encapsulated into CMA / RTP packets, a timestamp, sequence number, and FU-A identifier are injected into each CMA / RTP packet. This ensures that the access network central office device 3 can reassemble and restore the complete original CMAF media fragment (.m4s) file without errors based on the triple mechanism of timestamp, sequence number, and FU-A identifier. The sequence number and FU-A identifier are generated locally by device 2, but the timestamp cannot be generated locally. Instead, it is provided by the upstream media stream encapsulation gateway device 1. The purpose is to inject the start timestamp (PTS) of the IDR frame of the fragment into all RTP packets of the fragment, ensuring that these RTP packets belong to the same media fragment. The timestamp is provided in the "out-of-band metadata and black-box transmission" mode. The metadata is the PTS in the HTTP response header, while the black box is the CMAF media fragment (.m4s) file in the response body. The aforementioned "out-of-band metadata and black-box transmission" mode works as follows: When device 2 requests a CMAF media fragment (.m4s) file, device 1 returns the requested CMAF media fragment (.m4s) file, carrying the metadata PTS of the fragment file in its HTTP response header. This includes the timestamp (X-Fragment-Timestamp) of the first IDR frame of the fragment. Without parsing the CMAF media fragment (.m4s) file, device 2 obtains the timestamp of the first IDR frame of the fragment from the HTTP header. This allows device 2 to treat the CMAF media fragment (.m4s) file as a black box, split it into multiple RTP packets, encapsulate them into CMA / RTP packets, and inject the timestamp PTS of the IDR frame obtained from the HTTP header of the fragment into all RTP packets of that fragment. The same timestamp is used to mark all RTP packets of the fragment, ensuring that all RTP timestamps of the media fragment are the same, indicating that RTP packets with the same timestamp are RTP packets formed from the same media fragment.

[0176] The CMAF media fragment (.m4s) retrieval module 0602 initiates an HTTP request to the upstream device 1, receives the returned CMAF media fragment (.m4s) response, retrieves the media fragment, does not parse the CMAF media fragment (.m4s) file, packages the data into a structure, and writes it to the media fragment cache area 0603-1 of the cache management module 0603. Each channel has an independent circular buffer (caching 2 fragments), extracts metadata (timestamp, duration, sequence number) from its HTTP response header, and caches the metadata (including X-Fragment-Timestamp) and the starting PTS in 0603-2.

[0177] In the example above, by not parsing the CMAF media fragment (.m4s) file, a 2-second fragment of an 8K program is 30MB in size. Parsing a 30MB 8K fragment file requires reading and parsing the ISOBMFF structure. Even if only the header is read, performing this operation on every request consumes a lot of CPU resources, especially with 198 channels × 0.5 requests per second (because it is pulled every 2 seconds), which amounts to approximately 99 parsings per second, resulting in considerable cumulative overhead. Real-time parsing increases code complexity and the probability of errors, potentially introducing new bugs. Instead, separating metadata generation from fragmentation, with device 1 only performing static file services and header injection, and device 2 not parsing media fragments but obtaining the PTS from the returned file header, is simpler and more efficient.

[0178] The CMA / RTP packet encapsulation module 0604 reads the CMAF media segment (.m4s) file for each program from the cache and the metadata obtained from the HTTP header (including the start timestamp of the segment's IDR frame). It does not parse the media segments, treating them as a black box. It performs RTP FU-A binary fragmentation on the media segments, treating the CMAF media segment (.m4s) file as a binary stream and dividing it into small blocks of fixed size (1360 bytes). It adds an FU-A header (S, E markers) to each small block to generate consecutive RTP sequence numbers. Simultaneously, it injects the same timestamp PTS into all RTP packets for each .m4s segment. The timestamp source is the X-Fragment-Timestamp or tfdt parsing result from the HTTP response header provided by device 1. The clock frequency is 90000Hz. FU-A binary fragments are encapsulated into CMA / RTP packets and written to the CMAF fragment memory circular cache 0603-3 of the cache management module 0603, so that the CMA / RTP multicast stream encapsulation static multicast module 0605 can read them. Specifically: Input: Read an .m4s file (assuming size = 512KB) from the cache and the metadata of the fragment carried in the HTTP header of the fragment; Output: Each original media segment is split into multiple RTP packets (each RTP packet is approximately 1360-1400 bytes in size). The implementation may include the following steps: S1: File Reading: Read the .m4s file completely into the memory buffer; S2: MTU calculation: Assume network MTU = 1500 bytes; IP header (20 bytes) + UDP header (8 bytes) + RTP header (12 bytes) = 40 bytes; The actual maximum RTP payload is 1500 - 40 = 1460 bytes.

[0179] To be on the safe side, it is usually set to 1360-1400 bytes (taking into account the overhead of Layer 2).

[0180] S3: Sharding Rules: First slice: offset 0, length 1360 bytes, FU-A header flag [S]tart=1, S=1\E=0; Intermediate fragment: offset 1360, length 1360 bytes, FU-A header flag [None]=0, S=0\E=0; all intermediate fragments... and so on.

[0181] Last piece: Remaining data, length ≤ 1360 bytes, FU-A header marker [E]nd=1, S=0\E=1.

[0182] S4: RTP header settings: The timestamp is obtained from the HTTP header returned when the fragment is pulled from the upstream, and it is the timestamp PTS of the IDR frame within that fragment.

[0183] Timestamp calculation example:

[0184] Assumption: Fragment 1 start time: PTS = 1000ms; Fragment 2 start time: PTS = 3000ms (fragment duration 2 seconds); RTP clock frequency: 90000 Hz; calculate: Media Segment 1 RTP Timestamp = 1000 × 90 = 90000; Media Segment 2 RTP Timestamp = 3000 × 90 = 270000; All RTP packets in media segment 1 have timestamps equal to 90000; All RTP packets in Media Segment 2 have timestamps equal to 270000; This means that RTP packets of the same media segment have the same timestamp; in practice, the timestamp of each segment is obtained from upstream device 1.

[0185] Sequence number: CMA / RTP multicast stream encapsulation and static multicast module 0604 locally generated. The RTP packet sequence number of each program increases continuously, and also increases continuously across segments. The first packet starts with a random value. Assumption: The initial sequence number of the RTP stream in channel 1 is 0x1234 (randomly generated).

[0186] The first media segment (2 seconds, 8K) requires 23,000 RTP packets to be sent.

[0187] The sequence number range of the first media segment is: 0x1234 ~ 0x1234 + 22999.

[0188] The first packet sequence number of the second media segment is 0x1234 + 23000, and so on.

[0189] Thus, when device 3 receives: If you receive sequence number 0x1234, you know it's the start of the first fragment.

[0190] If you receive sequence number 0x1234+23000, you know it's the start of the second fragment (because after the packet with E=1, the next packet with S=1 has a consecutive sequence number).

[0191] Packet loss can be detected if the sequence number changes abruptly (for example, from 0x1234+1000 directly to 0x1234+2000).

[0192] SSRC: Fixed value for each program.

[0193] RTP header example: [IP header 20][UDP header 8][RTP header 12][RTP extension header?][RTP payload (including FU-A header) 1360].

[0194] FU-A segment header format: First RTP packet: RTP payload = [FU-A header (1 byte) | FU-A header (1 byte) | Data] 0x1C (NALU type=28) 0x80 (S=1) [data1360].

[0195] Intermediate RTP packets: RTP load = [0x1C | 0x00 (no flag) | data].

[0196] The last RTP packet: RTP load = [0x1C|0x40 (E=1)|data].

[0197] Device 2 does not need to parse the media content of the .m4s file; it only needs to treat it as a binary black box and divide it into binary chunks. It receives the chunks and their timestamps in a completely "out-of-band metadata + black-box transmission" mode. This design ensures both performance and protocol compatibility.

[0198] The fragment start timestamp (PTS) obtained from the HTTP header returned by device 1 is used by device 2 only for the timestamp of the segmented CMA / RTP packets. The PTS / DTS of each sample within each fragment is still in each RTP packet of the fragment, and is completely restored in the moof (movie fragment box) when device 3 reassembles the CMAF media fragments.

[0199] The characteristics of HTTP header transmission fragmentation start-up PTS are: Metadata is transmitted via HTTP headers and does not affect the fragmented data itself (the response body is still a clean CMAF fragment).

[0200] Device 2 only needs to parse these custom headers to obtain information such as timestamps required for RTP packaging, without needing to parse the fragment content.

[0201] The X- prefix is ​​a convention for custom headers, used to indicate non-standard fields.

[0202] This is precisely the concrete implementation of "out-of-band metadata + black-box transmission".

[0203] After the CMA / RTP packet encapsulation module 0604 completes the encapsulation of a fragmented CMA / RTP packet, it pushes the RTP packet into the CMA / RTP packet output queue buffer 0603-3 of the buffer management module 0603, so that the CMA / RTP multicast stream encapsulation static multicast module 0605 can read and encapsulate it into a UDP packet.

[0204] The CMA / RTP multicast stream encapsulation static multicast module 0605 reads CMA / RTP packets from the buffer and writes them to the output queue buffer. It then encapsulates these packets into a CMA / RTP Over UDP Over IP multicast stream according to the program ID, program name, and pre-planned multicast address. The multicast stream is then broadcast in static multicast mode. Static multicast means broadcasting all programs via multicast flooding without IGMP protocol activation. This enables live streaming of CMAF media fragments (.m4s) encrypted with the CENC standard, achieving low-latency, high-efficiency transmission over the backbone network. This allows the access network central office to receive the CMA / RTP Over UDP Over IP multicast stream, reassemble the CMAF media fragments (.m4s), and fully support access from home networks and various smart terminals, achieving low-latency transmission and playback of live CMAF media fragments (.m4s) files.

[0205] Example of multicast stream output: Program ID → Program Name → Multicast Address → Multicast Port 001 CCTV-1 139.1.1.1 5000 002 CCTV-2 139.1.1.2 5000 .... .... .... .... 198 XXTV-X 139.1.1.198 5000.

[0206] The initialization fragmentation and manifest retrieval module 0608 retrieves the fragmentation manifest HLSm3u8h / DASHmpd and initializes the fragments from the upstream media stream encapsulation gateway device 2, and writes them to the manifest cache 0603-4 and the initialization fragmentation permanent cache area 0603-5 of the cache management module 0603. It then exposes the manifest and init.mp4 output interface 0610 through the M3u8h / mpd manifest forwarding HTTP service module 0609 for device 3 to retrieve the manifest. Interface example: http: / / [Device2-IP] / manifest / channel_1.m3u8 http: / / [Device2-IP] / manifest / channel_1.mpd.

[0207] In one embodiment, for the service platform-side device 2, the service side provides a CMAF fragment .m4s file retrieval interface, an HLSm3u8h / DASHmpd manifest, and an initial fragment retrieval interface, which are respectively 2 100G and 2 10G interface; 2 on the user side 25G multicast stream output interface and 2 10G inventory and initial fragment output interface.

[0208] Each interface provides two paths, primary and backup, for interface redundancy. At the same time, device 2 also requires device-level disaster recovery backup to meet the secure broadcasting requirements of live television broadcasting services.

[0209] The CMAF media fragment (.m4s) retrieval module 0602 is responsible for receiving media fragments and extracting metadata, writing them to the CMAF fragment memory ring cache 0603-1 of the cache management module 0603. The CMA / RTP packet encapsulation module 0604 is responsible for reading media fragments and metadata, implementing triple-mechanism RTP encapsulation, and writing the encapsulated CMA / RTP packets to the CMA / RTP packet output queue cache 0603-3 of the cache management module 0603. The CMA / RTP multicast stream encapsulation static multicast module 0605 is responsible for reading RTP packets and encapsulating them into UDP streams for transmission.

[0210] In other words, the above modules form a pipeline, decoupled from the media fragmentation and transmission queue by a circular buffer, allowing them to run in parallel. Each module can be optimized independently. For example, the CMAF media fragment (.m4s) retrieval module 0602 can be accelerated using DPDK, and the CMA / RTP multicast stream encapsulation static multicast module 0605 can be offloaded to the smart network interface card.

[0211] In one embodiment, device 2 is designed with a three-layer architecture consisting of a data layer, a control layer, and a management layer. Each functional module is implemented according to the following functional and hardware support: Device 2: Media Stream Multicast Gateway Device 2 Data Layer: Responsible for high-speed data stream forwarding and processing, as shown in Table 6 below (Table 6 upper and Table 6 lower): Table 6

[0212] Table 6 (below)

[0213] Device 2's control layer is responsible for flow management, scheduling, and state control, as shown in Table 7 below: Table 7

[0214] Device 2's management layer is responsible for configuration, monitoring, and operation and maintenance, as shown in Table 8 below (Table 8 upper and Table 8 lower): Table 8

[0215] Table 8 (below)

[0216] The functional modules of the data layer of the streaming media gateway (device 3) from UDP / RTP / CMAF fragmentation to CMAF media fragment reassembly (.M4s) at the access network central office are described below: In one embodiment, the data layer functional module of the streaming media reassembly gateway (device 3) for CMA / RTP fragmentation to reassembly of CMAF media fragments (.M4s) is as follows: Figure 5 As shown, the data layer of device 3 includes: a CMA / RTP multicast stream receiving interface 0801, a CMA / RTP multicast stream to CMA / RTP layer parsing module 0802, a cache management module 0803, a CMA / RTP packet parsing module 0804, a CMAF media fragment reassembly module 0805, an HTTP channel interface 0806, a manifest / initialization fragment retrieval module 0807, an HTTP service module 0808, and a unicast stream output interface 4. The 25G or 100G high-speed interface 0809 includes a device 3 cache management module 0803, which comprises: a CMA / RTP packet circular buffer 0803-1, an RTP FU-A fragment reassembly buffer 0803-2, a CMAF media fragment (.m4s) circular buffer 0803-3, an HLSm3u8h / DASHmpd manifest buffer 0803-4, and an initialization fragment .mp4 permanent buffer 0803-5, to provide data caching and retrieval for related modules during data processing.

[0217] In one example, the streaming media gateway (device 3) data processing flow may include: S1: CMA / RTP multicast stream to CMA / RTP layer parsing module 0802: The CMA / RTP static multicast stream output from receiving device 2 is monitored in promiscuous mode via multicast stream receiving interface 0801. The CMA / RTP packets are parsed and stored in the CMA / RTP packet circular buffer 0803-1 of the buffer management module 0803. The buffer is indexed by SSRC + channel ID + sequence number, and its capacity is the total RTP packets of one CMAF media segment. Buffer timeout: 200ms.

[0218] S2: CMA / RTP packet parsing module 0804: CMA / RTP packets are read from the CMA / RTP packet circular buffer 0803-1 of the cache management module 0803. The RTP FU-A fragments of the RTP packet payload are parsed out and written to the RTPFU-A fragment reassembly buffer 0803-2 of the cache management module 0803 according to the triple identifier of timestamp, sequence number and FU-A. After each complete fragment of RTP packet is parsed and cached, the complete CMAF fragment reassembly module is notified to read it.

[0219] S3: CMAF Media Fragmentation and Reassembly Module 0805: Read the RTP FU-A fragment payload data of the complete CMAF media fragment from the RTP FU-A fragment reassembly buffer 0803-2 of the buffer management module 0803, reassemble the complete CMAF media fragment (.M4s) and store it in the CMAF media fragment (.m4s) circular buffer 0803-3 of the buffer management module 0803. The buffer duration is 60s, and 30 media fragments with a buffer duration of 2s are buffered. The index is: channel ID + sequence number.

[0220] S4: Inventory / Initialize Fragmentation Module 0807: The system retrieves the HLSm3u8h and DASHmpd manifest files of the CMAF fragment (.m4s) provided by device 2 via HTTP channel interface 0806, and then rewrites and synchronizes the manifest files before storing them in the HLSm3u8h / DASHmpd manifest cache 0803-4, with channel ID index.

[0221] The initialization fragment (.mp4) provided by device 2 is retrieved via HTTP channel interface 0806 and stored in the permanent cache area 0803-5 (permanent within version) of the initialization fragment .mp4 in cache management module 0803. This implements version management, listening for two triggers: version update and device restart. Upon either trigger, a new initialization fragment (.mp4) is retrieved to overwrite the original version for terminal retrieval. Support for terminal pre-retrieval of initialization fragments for local caching and random retrieval is supported. Pre-retrieval of initialization fragments by the terminal can reduce channel switching time by 20-50ms.

[0222] S5: CMAF Media Fragments (.m4s) / HLSm3u8h / DASHmpd Manifestation / Initialize Fragments (.mp4) HTTP Service Module 0808: It provides the terminal with a service to pull initial fragments / media stream lists / media fragments by path. The initial fragments support pre-pull and random pull services.

[0223] Based on the end user's request, the initial fragment (.mp4) is read from the permanent cache area 0803-5 of the initial fragment .mp4 in the cache management module 0803 and forwarded to the destination user. It can support pre-fetching and random fetching. Based on the end user's request, the HLSm3u8h / DASHmpd manifest of the CMAF media fragment (.m4s) is read from the HLSm3u8h / DASHmpd manifest cache 0803-4 and forwarded to the target user; Based on the end user's request, the CMAF media fragment (.m4s) file is read from the CMAF media fragment (.m4s) circular buffer 0803-3 of the cache management module 0803 and forwarded to the destination user.

[0224] The specific measures to implement the above process are as follows: CMA / RTP multicast stream receiving interface 0801, providing 2 The 25G rate primary and backup interfaces, in promiscuous mode, listen to and receive CMA / RTP Over UDP Over IP multicast streams transmitted from the core network, and forward them to the CMA / RTP multicast stream to the CMA / RTP layer parsing module 0802.

[0225] The CMA / RTP multicast stream is received by the CMA / RTP layer parsing module 0802. All multicast streams are received and quickly classified based on their multicast addresses (198 filters, assuming 198 live broadcast services). Zero-copy reception and parsing of the CMA / RTP packets result in their being written to the CMA / RTP packet circular buffer 0803-1 in the buffer management module 0803. Each channel's CMA / RTP packets are buffered separately for a fixed duration (2 seconds) using the program ID as the partition (unlocked circular buffer, independent for each channel). The receive buffer size for each channel must be large enough to hold all RTP packets of a complete segment (approximately 34.7MB at 8K). The buffer index uses the program ID and RTP sequence number, cached in timestamp and sequence number order for fast reading and parsing by the CMA / RTP packet parsing module 0804.

[0226] The CMA / RTP multicast stream to CMA / RTP layer parsing module 0802: Listens for and receives all UDP multicast streams in promiscuous mode via a 25G network card. It quickly identifies the channel based on the destination IP and port (each channel corresponds to a fixed multicast address + port). It parses the UDP / IP header and extracts the RTP packets (including the RTP header, FU-A header, and payload). The RTP packets are then placed into the corresponding receive buffer (an unlocked circular buffer, independent for each channel) according to the channel. No RTP parsing or reassembly is performed to ensure high throughput.

[0227] Specifically, DPDK or smart NIC offloading is used to achieve zero-copy. The receive buffer size for each channel must be large enough to hold all RTP packets of a complete media segment (approximately 34.7MB at 8K). The buffer index uses RTP sequence numbers for quick location by the CMA / RTP packet parsing module 0804.

[0228] The CMA / RTP packet parsing module 0804 reads CMA / RTP packets for each channel from the cache, parses the RTP header (sequence number, timestamp, SSRC) and FU-A header (S / E flag), and after parsing out the RTP FU-A fragments of the RTP payload, stores them sequentially into the RTP FU-A fragment reassembly cache area 0803-2 of the cache management module 0803. The RTP FU-A fragments are cached according to their sequence numbers for a duration of 2 seconds and an expiration time of 200ms, so that the CMAF media fragment reassembly module 0805 can read and reassemble the CMAF media fragments (.m4s). The CMA / RTP packet parsing module 0804 reads RTP packets from the buffer, sorts them according to their sequence numbers, checks the S / E flag in the FU-A header, and when a small fragment (S=1) is detected, it allocates a reassembly buffer and writes the RTP payload (with the header removed) sequentially until the E=1 flag is received. This process takes 200ms. If the timeout occurs, the packet is treated as a lost packet. The CMA / RTP packet parsing module 0804 is used to parse CMA / RTP packets according to the rules of the triple mechanism encapsulation of CMA / RTP packets in device 2: it reads RTP packets from the receive buffer of each channel and parses the RTP header (sequence number, timestamp, SSRC) and FU-A header (S / E flags).

[0229] The three-tiered restructuring mechanism includes: 1) Serial number: Check for continuity. If the sequence is out of order, temporarily store the packet or wait. If the sequence changes, trigger packet loss detection.

[0230] 2) FU-A flag: Identify the fragment boundary based on the S / E flag and write the payload data sequentially into the reassembly buffer (each channel is independent and the size is equal to the duration of a media fragment).

[0231] 3) Timestamp: Verify that the timestamps (PTS) of all RTP packets in the same media segment are consistent.

[0232] Manage the reassembly state machine for each channel, including the starting sequence number of the current fragment, the received packet bitmap, the expected sequence number, etc.

[0233] 4) Timeout Management: The timeout starts from the first RTP packet (S=1) received for a media fragment. If all packets are not received within 200ms (based on the sequence number range and the E=1 flag), the fragment is determined to be lost, the relevant status is cleared, and FEC or a retransmission request may be triggered.

[0234] 5) When a media fragment is detected to be complete (E=1 is received and all packets have been reassembled in order), a completion notification is sent to the CMAF fragment reassembly module 0805, and the reassembly buffer pointer or completion event is transmitted.

[0235] In other words, the main implementation mechanisms of the above three-tier mechanism are: Timestamp (PTS): RTP packets with the same timestamp belong to the same media fragment; Sequence Number: First, it determines the order of RTP packets in the reassembled fragment; second, it determines how many RTP packets are in the fragment; third, the RTP payload sequence number not only increases sequentially within the fragment, but also increases across fragments, thus determining the order of the media fragments; FU-A Identifier: S=1, E=0, then it is the first RTP packet of the media fragment; S=0, E=0, then all are intermediate RTP packets of the media fragment; S=0, E=1, then it is the last RTP packet of the media fragment. The CMA / RTP packet parsing module 0804 parses RTP packets according to the aforementioned triple mechanism and stores the RTP packet payload sequentially into the RTP FU-A fragment reassembly buffer 0803-2, thus completing the reassembly of the original media fragments.

[0236] The CMA / RTP packet parsing module 0804 can process different channels in parallel using multiple threads, with each channel bound to an independent CPU core. It uses a bitmap to record received packets to correctly determine integrity in case of out-of-order delivery. The reassembly buffer employs a double-buffering mechanism: one for the current fragment and the other for the previous or next fragment of RTP packets, to avoid write and read operations waiting for each other.

[0237] After reading each RTP packet from the receive buffer, the CMA / RTP packet parsing module 0804 can perform the following operations: Check RTP sequence number: determine if it is continuous, and trigger packet loss detection if a jump occurs.

[0238] Parse the FU-A header: Identify fragment boundaries based on the S (start) and E (end) flags.

[0239] Record timestamps: Ensure that all RTP packets of the same media segment have the same timestamp (or handle timestamp changes according to standards).

[0240] Write the payload data sequentially into the reassembly buffer of the current channel.

[0241] When a packet with E=1 is received, it indicates that all RTP packet payloads of the media fragment have been written to the reassembly buffer. At this time, the CMA / RTP packet parsing module 0804 notifies the CMAF media fragment reassembly module 0805 to read and reassemble the fragment. The CMA / RTP packet parsing module 0804 then starts writing the next fragment RTP packet payload in the other buffer of the dual buffer, without waiting for each other.

[0242] In its implementation, the CMA / RTP packet parsing module 0804 operates on a streaming basis: once the first packet of a media segment (S=1) is received, data is immediately written to the reassembly buffer. Subsequent packets are appended as they arrive, without waiting for all packets to arrive before writing begins.

[0243] However, the CMA / RTP packet parsing module 0804 relies on sequence numbers and the FU-A flag to ensure the correct writing order. If the network is out of order, the CMA / RTP packet parsing module 0804 needs to sort the packets first (or insert them by sequence number using the reassembly buffer), but the probability of RTP packets being out of order in the network is usually low, and the FU-A design itself supports out-of-order (because each packet has an independent sequence number, and they can be sorted according to the sequence number during reassembly).

[0244] The CMAF media fragment reassembly module 0805 listens to the RTP FU-A sub-fragments of the RTP payload written to the reassembly buffer by the CMA / RTP packet parsing module 0804. When the RTP FU-A sub-fragments of a complete CMAF media fragment (.m4s) are all written according to the triple mechanism, the RTP FU-A sub-fragments of the CMAF media fragment (.m4s) are quickly read, reassembled and encapsulated into the original CMAF media fragment (.m4s), and written to the CMAF media fragment (.m4s) circular buffer 0803-3 of the buffer management module 0803. The buffer duration is 60s, and it can buffer 30 media fragments (.m4s) with a duration of 2s. The buffer is indexed by channel ID and sequence number. At the same time, the data that has been read in the reassembly buffer is deleted, waiting for the reading and reassembly of the next CMAF media fragment (.m4s) RTP FU-A sub-fragments.

[0245] The complete .m4s file is reassembled using a triple mechanism of sequence number sorting, timestamp, and FU-A identifier. Packet loss detection and interpolation are then performed to reassemble the complete .m4s binary file. The reassembled CMAF media segment (.m4s) file for each program is written to a circular buffer media segment buffer with a sliding window and a fixed duration of 60 seconds. In actual caching, a three-level storage approach can be used: from memory to SSD, then to a mechanical hard drive (optional), with an LRU eviction algorithm.

[0246] The CMAF media fragment reassembly module 0805 only processes complete CMAF fragments. It learns that a media fragment has been reassembled through the notification mechanism (e.g., callback, message queue, semaphore) of the CMA / RTP packet parsing module 0804, and then reads the complete data from the reassembly buffer and stores it in memory or SSD.

[0247] The reassembly buffer is exclusively written to by the CMA / RTP packet parsing module 0804 during fragment reassembly. After completion, the CMA / RTP packet parsing module 0804 transfers control to the CMAF media fragment reassembly module 0805 (or reads directly through shared memory), after which the buffer can be reclaimed or reused.

[0248] For the CMAF media fragment reassembly module 0805, it can listen for completion notifications from the CMA / RTP packet parsing module 0804 (via message queue or callback). The CMAF media fragment reassembly module 0805 reads complete media fragment data from the reassembly buffer (which has already been filled by the CMA / RTP packet parsing module 0804). The CMAF media fragment reassembly module 0805 asynchronously writes data to memory or SSD: writing the data to a file with a filename format like ch1_12345.m4s (channel ID and sequence number). The CMAF media fragment reassembly module 0805 updates the memory index table, recording the file path, timestamp, sequence number, size, etc., corresponding to the media fragment, for querying by the HTTP service module 0808. It maintains a 60-second sliding window cache: periodically or on demand, evicting fragment files older than 60 seconds and simultaneously deleting the corresponding entry from the index table.

[0249] In other words, asynchronous I / O (e.g., libaio or io_uring) improves write performance and avoids blocking. The index table can use a hash table or a tree from the CMA / RTP packet parsing module 0804, supporting fast lookups. After a write operation is complete, the manifest / initialization shard pull module 0807 can be notified for manifest and shard initialization synchronization. The manifest / initialization shard pull module 0807 can also ensure that the manifest and shard initialization are ready through a pre-caching mechanism.

[0250] The manifest / initialization fragment retrieval module 0807 retrieves the CMAF media fragment (.M4s) file manifest HLSm3u8h / DASHmpd and initial fragments from device 2, retaining the manifest's encrypted metadata and key URL unchanged. It rewrites the manifest media file URL, making the media file URL point to device 3 itself. After synchronizing the CMAF media fragment (.M4s) file and the media manifest, the rewritten and synchronized HLSm3u8h / DASHmpd manifest is cached in the HLSm3u8h / DASHmpd manifest cache 0803-4 of the cache management module 0803, so that the user-end device can retrieve the manifest and the corresponding media file CMAF media fragment (.M4s).

[0251] The manifest retrieval module 0806 periodically (e.g., every 2 seconds) retrieves the raw manifest (HLS m3u8 or DASH mpd) for each channel from device 2 via HTTP. It parses the raw manifest, extracting fragment sequence numbers, durations, DRM information, etc. The manifest is then rewritten: the fragment URLs are replaced with local HTTP addresses on device 3 (e.g., http: / / device3-IP / cache / ch1 / seg_12345.m4s), while retaining DRM tags and license URLs. Synchronization information (e.g., RTP multicast address, start timestamp) is injected as custom tags to aid in debugging. The rewritten manifest is stored in an in-memory manifest cache with a validity period (e.g., 1 second) for the HTTP service module 0807 to read. Working in conjunction with the CMAF media fragment reassembly module 0805, it ensures that the fragment sequence numbers in the manifest do not predate the actual media fragments in memory or the SSD cache. This can be achieved by checking the index table of the CMAF media fragment reassembly module 0805 or by relying on the pre-caching mechanism (CMAF media fragment reassembly module 0805 ensures that the latest fragment is ready).

[0252] In other words, manifest retrieval uses persistent HTTP connections and TCP fast opening to reduce latency. Manifest caching can use LRU (a caching algorithm) or timed refresh, independent for each channel. If a retrieval fails, the previous manifest (with expiration warnings) can be used or an alarm can be triggered.

[0253] The manifest / initialization fragment retrieval module 0807 generates a new manifest file for the terminal to request. The rewrite rules are as follows: Chunk URL Replacement: Replaces the original media chunk URL (pointing to device 2 or upstream) with the local HTTP address of device 3.

[0254] Original source: https: / / cdn-origin.com / ch1 / seg_12345.m4s; Rewrite: http: / / [Device3-IP] / cache / ch1 / seg_12345.m4s; DRM information remains unchanged: the EXT-X-KEY label is retained as is, ensuring that the terminal still requests authorization from the original DRM license server.

[0255] Add synchronization information (optional): Custom tags can be added to the manifest to indicate the RTP multicast stream information corresponding to each segment, which is convenient for internal debugging.

[0256] The rewritten list is stored in the memory or SSD of device 3, with a very short cache expiration time (e.g., 1 second).

[0257] The synchronization mechanism between the playlist and the media requires that, during playback on the terminal, the acquired playlist and the reconstructed media segments be aligned in time. For example, the Nth segment listed in the playlist must be the segment that device 3 has just reconstructed from the multicast stream.

[0258] In one example, the synchronization strategy may include: 1) Timestamp alignment: When sending RTP streams, device 2 sets the same RTP timestamp for each CMAF fragment, which is proportional to the fragment's PTS (display timestamp).

[0259] After reassembling the fragments, device 3 can record the RTP timestamp of the fragment and establish a mapping with the time information in the list (e.g., EXT-X-PROGRAM-DATE-TIME).

[0260] 2) Serial number alignment: The EXT-X-MEDIA-SEQUENCE in the list indicates the current fragment sequence number.

[0261] Device 2 can send this serial number via RTP extension header or a custom method along with the stream, and Device 3 verifies the consistency of the serial number during reassembly.

[0262] 4) Synchronous fault tolerance: If device 3 finds that the fragments in the list are not present in its local cache (possibly due to RTP packet loss or latency), execute: a. Wait for at most one fragment duration (e.g., 2 seconds) to see if it can be recovered from subsequent RTP packets.

[0263] b. If a timeout occurs, retrieve the fragment from device 2 via HTTP origin server as a backup.

[0264] c. Skip this segment in the playlist (requires EXT-X-DISCONTINUITY support) to avoid playback interruption.

[0265] 5) Fast startup on the first frame: Device 3 pre-caches at least one complete fragment for each channel (in practice, multiple fragments may be cached), and immediately returns the URL of the prepared fragment when the terminal requests the manifest, ensuring that the first frame time is ≤ 500ms.

[0266] HTTP service module 0808 is the service module for end users to obtain initial fragments and CMAF media fragment (.m4s) files corresponding to the HLSm3u8h / DASHmpd manifest. Device 3 provides unicast stream output interface 4 on the user side. 25G or 100G high-speed interface 0809, user-end smart terminals access the unicast stream output interface 4 of device 3 through the access network via a home router. The 25G or 100G high-speed interface 0809 obtains the program guide through the terminal APP or EPG and sends a request. Through the HTTP service module 0807, it obtains the initial segment, HLSm3u8h / DASHmpd list and corresponding CMAF media segment (.m4s) file. At the same time, it obtains the DRM key KID and URL through the list, and obtains CK from the key server to decrypt and play the CENC encrypted CMAF media segment (.m4s) file.

[0267] The HTTP service module 0807 listens for HTTP requests from end users (100G interface). It handles manifest requests: based on the request's channel and type (HLS / DASH), it reads the rewritten manifest from the manifest cache maintained by the manifest / initialization fragment retrieval module 0807 and returns it to the user. It handles media fragment requests: based on the fragment identifier in the URL, it looks up the corresponding memory or SSD file path in the memory index table of the CMAF media fragment reassembly module 0805 and sends the file content using sendfile with zero-copy. If the fragment does not exist (rarely, such as a cache miss), it can return to the CMAF media fragment reassembly module 0805 or trigger origin pull logic.

[0268] In other words, the HTTP service module 0807 uses a high-performance HTTP server (e.g., Nginx, Caddy) or a self-developed epoll-based server. The manifest cache and in-memory index table need to support concurrent reads, using read-write locks or RCU.

[0269] In one embodiment, the functions, inputs, outputs, etc., of each module in the core layer of device 3 can be shown in Table 9 below: Table 9

[0270] Specifically: 1. The receiving module is responsible for receiving UDP multicast packets from the network, separating different channels according to the destination IP / port, parsing RTP packets, and putting the RTP packets into the receive buffer (circular buffer) of each channel. In the implementation, only minimal processing is performed to maintain the high performance requirement.

[0271] 2. The reassembly module reads RTP packets from the receive buffer of each channel, executes RTP reassembly logic (checking sequence number, FU-A flag, and timestamp), and writes the payload data sequentially into the reassembly buffer. When a fragment is detected as complete (receiving the E flag and consecutive sequence numbers), it notifies the reassembly storage module, while simultaneously managing timeouts (200ms) and packet loss handling.

[0272] 3. Reassembly Storage Module: Listens for notifications from the reassembly module. When a fragment of a channel is reassembled, it asynchronously writes the data (complete CMAF fragment) from the reassembly buffer to the SSD and updates the memory index table (fragment URL path, timestamp, etc.). It also manages the SSD cache window (a 60-second sliding window) and is responsible for evicting expired fragments.

[0273] 4. Initialize the fragment processing module. At startup, it pulls the initial fragment init.mp4 cache from device 2 into the initial fragment cache area to implement version management. It listens for two triggers: version and device restart. If either trigger occurs, it will pull and overwrite the original version so that the terminal can pull it.

[0274] 5. Inventory Processing Module: Periodically (every 2 seconds), it retrieves the original inventory from device 2 via HTTP, parses it, rewrites the fragment URL to the local address, adds necessary synchronization information (such as multicast mapping), and then stores the rewritten inventory in the memory inventory cache (valid for 1 second) for use by the HTTP service module 0807. Simultaneously, it collaborates with the CMAF fragment reassembly module 0805 to ensure that the fragment sequence number in the inventory is consistent with the fragments in memory or SSD cache (synchronization).

[0275] 6. HTTP Service Module: Listens for HTTP requests from end users and returns initial fragments, manifests, or media fragments based on the request path. For manifest requests, it reads the rewritten manifest from the manifest cache; for fragment requests, it reads the file from memory or SSD cache and sends it via zero-copy; for initial fragment requests, it reads from the initial fragment .mp4 permanent cache.

[0276] In other words, the reassembly module is the brain of the reassembly process, responsible for handling all logic related to the RTP protocol (sequence number, timestamp, FU-A). The reassembly module reads RTP data from the receive buffer of the receiving module, without waiting for the entire fragment to arrive before starting; instead, it processes the data as it is received. The receiving module only performs stateless reception and does not parse RTP content to ensure the optimal performance of the receiving thread. The reassembly module does not directly handle RTP packets; it only processes complete CMAF fragments and interfaces with the HTTP service layer.

[0277] Specifically, the reassembly module is responsible for ensuring the complete reassembly of fragments using timestamps, sequence numbers, and FU-A identifiers, and may include: S1: The reassembly module reads each RTP packet from the receive buffer.

[0278] S2: Check RTP sequence number: determine if it is continuous, and trigger packet loss detection if a jump occurs.

[0279] S3: Parse the FU-A header: Identify fragment boundaries based on the S (start) and E (end) flags.

[0280] S4: Record timestamps: Ensure that all RTP packets in the same fragment have the same timestamp (or handle timestamp changes according to standards).

[0281] S5: Write the payload data sequentially into the reassembly buffer of the current channel.

[0282] In its implementation, the reassembly module does not need to wait for the first buffered RTP packet to complete a fragment. The reassembly module operates in a streaming manner: once the first packet of a fragment (S=1) is received, data is immediately written to the reassembly buffer. Subsequent packets are appended as they arrive, without waiting for all packets to arrive before starting.

[0283] However, the reassembly module relies on sequence numbers and the FU-A flag to ensure correct write order. If the network is out of order, the reassembly module first sorts the packets (or inserts them by sequence number using the reassembly buffer). RTP packets typically have a low probability of being out of order in the network, and the FU-A design itself supports out-of-order delivery (because each packet has an independent sequence number, allowing sorting based on sequence number during reassembly). When a packet with E=1 is received, it indicates that all payloads for that fragment have been written to the reassembly buffer. At this point, the reassembly module notifies the reassembly storage module that fragment reassembly is complete.

[0284] In the example above, the rebuild buffer might be written to by the rebuild module and then read by the rebuild storage module. If each read involves a memory copy, it increases CPU overhead. Therefore, it can be optimized as follows: 1) Direct file writing: During the reconstruction process, the reconstructing module directly appends the payload data to a temporary file (e.g., using a memory-mapped file). Once the reconstruction is complete, the file only needs to be closed, and the reconstructing storage module does not need to make any additional copies.

[0285] 2) Zero-copy transfer: Using shared memory or pipes, the reorganization storage module can directly obtain a reference to the reorganization buffer.

[0286] 3) Writing using memory reorganization and asynchronous file methods: The reorganization buffer uses memory (e.g., a circular buffer or linked list), and the reorganization storage module writes the data. After reorganization is complete, the reorganization module hands the buffer pointer to the reorganization storage module, which then starts an asynchronous write task to write the data to the SSD. Simultaneously, the reorganization module can continue processing the next fragment.

[0287] In one embodiment, the internal timing of device 3 is exemplified as follows: Assuming an 8K packet size of 30MB, approximately 23,130 RTP packets, and device 2 sending at a line rate of 25Gbps, the transmission time is approximately 9.6ms. Network propagation delay is negligible (assumed to be <1ms).

[0288] Internal timing of device 3: t=0ms: The CMA / RTP multicast stream receives the first RTP packet (S=1) at the CMA / RTP layer parsing module 0802 and stores it in the receive buffer.

[0289] t=0.1ms: The CMA / RTP packet parsing module 0804 polls for a new packet, parses it, and begins writing it to the reassembly buffer.

[0290] t=0~9.6ms: All packets are received successively, and the CMA / RTP packet parsing module 0804 continues to write.

[0291] t=9.7ms: The last packet was received (E=1), and the reassembled buffer was complete.

[0292] t=9.8ms: CMA / RTP packet parsing module 0804 notifies CMAF media fragment reassembly module 0805.

[0293] t=10ms: The CMAF media fragment reassembly module 0805 begins writing the reassembly buffer data to memory or SSD (assuming a write latency of 10ms).

[0294] t=20ms: The fragment is completely stored in memory or SSD and is available for terminal request.

[0295] Therefore, the entire process from receiving the first packet to fragmentation takes about 20ms, which is much less than the 200ms timeout and also much less than the fragmentation time of 2 seconds.

[0296] In one embodiment, the cache parameters of device 3 can be as shown in Table 10 below: Table 10

[0297] The receive module's receive buffer and the reassembly module's reassembly buffer are memory caches, while the reassembly storage module is a memory or SSD cache. The total memory requirement for the receive and reassembly modules is approximately 12.8GB. Including the operating system and other overhead, it is recommended that the device have at least 32GB of RAM. 178GB of RAM or SSD is recommended, with 240GB or more suggested.

[0298] In one embodiment, the mechanism for several cache nodes is as follows: 1. How the receive buffer (maintained by the receive module) works: This is a circular buffer, independent for each channel. The receive module writes received RTP packets sequentially, with each packet occupying one slot. Packets are not immediately deleted but wait for the reassembly module to read them. The reassembly module reads packets from the buffer and marks the slot as reusable (or moves the read pointer) after reading. If the reassembly module is slow to read, packets may remain in the buffer for a longer period, but the buffer capacity is limited (designed for a complete fragment). If the reassembly module is temporarily unable to read some packets while waiting for out-of-order packets, these packets will remain in the buffer until: the reassembly module reads them (when all the required packets arrive, the reassembly module reads and processes them sequentially); or after a timeout (200ms), the entire fragment is discarded, and the associated packets are cleared (by resetting the read pointer).

[0299] 2. Out-of-order packet handling and 200ms timeout: Out-of-order situation: For example, the order of fragmented RTP packets should be 1, 2, 3, 4, 5, but the received order is 1, 5, 2, 3, 4.

[0300] Upon receiving packet 1 (S=1), the reassembly module begins reassembly and writes the payload of packet 1 into the reassembly buffer. Simultaneously, it records the sequence numbers 2, 3, 4, and 5 that need to be waited for. When packet 5 is received, the reassembly module checks its sequence number and finds that packets 2, 3, and 4 are missing. Therefore, it does not process packet 5 immediately but temporarily stores it (in fact, packet 5 remains in the receive buffer; the reassembly module will not read it until all preceding packets arrive, or the reassembly module can read it earlier and insert it into the reassembly buffer according to its sequence number, depending on the reassembly module's design strategy).

[0301] To improve efficiency, the reassembly module reads all packets from the receive buffer, but not in order. In fact, RTP reassembly typically requires concatenating the payload to the reassembly buffer in sequence number order because FU-A requires sequential concatenation. If packets are out of order, the received packets may be temporarily placed in a temporary sorting buffer (or directly inserted into the correct position in the reassembly buffer). The reassembly module actively reads; it can read all packets, but needs to determine whether it can currently write to the reassembly buffer based on the sequence number. If not (e.g., due to missing packets), it can first save the packets to a reordering buffer (which could be the receive buffer itself, as long as all packets are retained), and then wait for the missing packets to arrive.

[0302] 200ms Timeout: Starting from the receipt of the first packet (S=1), if all packets of the fragment (determined by the sequence number range) have not arrived within 200ms, the fragment is considered lost. The reassembly module will clear the relevant state and notify the upper layer. At this time, packets belonging to the fragment in the receive buffer will also be overwritten by subsequent writes (because the read pointer may have already passed them or been explicitly discarded).

[0303] 3. Maximum dwell time of RTP packets in the receive buffer: Ideally, the reassembly module reads quickly, and RTP packets remain for a very short time (a few milliseconds). In the worst case, due to out-of-order waiting, a packet may remain for close to 200ms. If it exceeds 200ms, the entire fragment is discarded, rendering these packets meaningless. 200ms is the timeout set for waiting for out-of-order packets; that is, 200ms is a waiting threshold set to cope with network out-of-order issues and packet loss. Its purpose is to give the network enough time for out-of-order packets or retransmitted packets to arrive, while ensuring low latency (without affecting the 500ms first frame). This is because: sending an 8K fragment (30MB) at a 25Gbps line rate takes only about 9.6ms, and with network propagation delay (usually <10ms), all packets should arrive within tens of milliseconds under normal circumstances. 200ms is much longer than normal latency, sufficient to cover most network jitter (such as route convergence and occasional queuing delays) without excessively slowing down the system. If it takes more than 200ms to arrive, it is most likely that the packet has been lost. Continuing to wait will only increase the playback delay, so it is advisable to discard the packet and trigger recovery (FEC or retransmission).

[0304] In one embodiment, device 3 (streaming media reassembly gateway) is designed with a three-layer architecture of data layer, control layer and management layer. The detailed functions and hardware support of each layer's functional modules are described in detail below.

[0305] The following table 11 (Table 11 top and Table 11 bottom) illustrates the function of the data layer of device 3. The data layer of device 3 is used for high-speed data processing and forwarding.

[0306] Table 11

[0307] Table 11 (below)

[0308] Table 12 below illustrates the function of the device 3 control layer, which is used for stream synchronization and resource management.

[0309] Table 12

[0310] Table 13 below illustrates the function of the device 3 management layer, which is used for gateway management and monitoring.

[0311] Table 13

[0312] In one embodiment, the interaction and data exchange of the core module of the data processing layer of device 3 are as follows: 1. From CMA / RTP multicast stream to CMA / RTP layer parsing module 0802 to CMA / RTP packet parsing module 0804: Through a lock-free circular buffer, CMA / RTP packet parsing module 0804 reads RTP packets from the receive buffer of each channel.

[0313] 2. Interaction between CMA / RTP packet parsing module 0804 and CMAF media fragment reassembly module 0805: Completion notifications can be sent via an event queue or a shared memory flag. Fragment metadata (channel ID, sequence number, reassembly buffer address) is transmitted using a message queue (such as an SPSC queue), and the thread pool of CMAF media fragment reassembly module 0805 handles the writes.

[0314] 3. Interaction between the CMAF media fragment reassembly module 0805 and the manifest / initialization fragment retrieval module 0807: Indirect synchronization. When generating the manifest, the manifest / initialization fragment retrieval module 0807 can check if there is a corresponding fragment in the index table of the CMAF media fragment reassembly module 0805. If not, it waits (or returns the old manifest). However, more efficient is that the CMAF media fragment reassembly module 0805 guarantees that the latest fragment is always written first, and the manifest / initialization fragment retrieval module 0807 completely trusts the pre-caching mechanism of the CMAF media fragment reassembly module 0805.

[0315] 4. List / Initialization Shard Pull Module 0807 to HTTP Service Module 0808: The list and initialization shard caches are shared memory cache areas, which are directly read by HTTP Service Module 0808.

[0316] 5. From CMAF media fragment reassembly module 0805 to HTTP service module 0808: The memory index table is a shared cache area, and HTTP service module 0808 looks up the file path by filename.

[0317] In one embodiment, the key design consideration for device 3 is: 1) Buffer size and timeout: 1.1 Receive Buffer: Each channel needs to hold all RTP packets of a complete fragment (approximately 34.7MB at 8K), and the total memory for 198 channels is approximately 6.87GB.

[0318] 1.2 Reassembly Buffer: One for each channel, the size of which is equal to one fragment (30MB in 8K), with a total memory of approximately 5.94GB for 198 channels.

[0319] 1.3 200ms Timeout: The timer starts from the arrival of the first packet and is used to handle out-of-order packets and packet loss. This value is much larger than the normal transmission time (<10ms) to ensure low latency while tolerating network jitter.

[0320] 2) Concurrency and Thread Model: 2.1 CMA / RTP multicast stream to CMA / RTP layer parsing module 0802: single-threaded or multi-threaded (distributed by queue), using DPDK polling.

[0321] 2.2 CMA / RTP packet parsing module 0804: Each channel has an independent thread, bound to different CPU cores.

[0322] 2.3 CMAF Media Segmentation and Reassembly Module 0805: Thread pool (e.g., 8-16 threads) to handle asynchronous writes.

[0323] 2.4 List / Initialization Fragment Retrieval Module 0807: Single-threaded timed retrieval, or one timer per channel.

[0324] 2.5 HTTP Service Module 0808: Multi-threaded HTTP service, using epoll.

[0325] 3) Synchronization and Consistency: Sharding Completion and Inventory Update: The inventory / shard initialization pull module 0807, when generating a new inventory, should ensure that the shards referenced in the inventory are already in memory or on the SSD. This can be achieved through the following methods: 3.1 Pre-caching: The CMAF media fragment reassembly module 0805 writes immediately after fragment reassembly is completed. The fetching cycle of the manifest / initialization fragment fetching module 0807 is slightly later than the fragment completion time (for example, fetching every 2 seconds, while fragments are completed every 2 seconds, with a difference of a few hundred milliseconds).

[0326] 3.2 Inspection Mechanism: Before rewriting the list, the list / initialization fragment retrieval module 0807 quickly queries the index table of the CMAF media fragment reassembly module 0805. If the latest fragment is not yet ready, the old list is used or the fragment is skipped (insert #EXT-X-DISCONTINUITY).

[0327] 4) Troubleshooting: 4.1 Packet Loss Recovery: After detecting packet loss, the CMA / RTP packet parsing module 0804 can attempt FEC decoding (if FEC is enabled on device 2) or request retransmission through the backup TCP channel. If recovery fails after a 200ms timeout, the fragment is discarded, and the CMAF media fragment reassembly module 0805 is notified to skip it (not write it). At the same time, the manifest / initial fragment retrieval module 0807 skips the fragment in the manifest.

[0328] 4.2 Cache miss: HTTP service module 0808 receives a fragment request but the file does not exist. It can return to CMAF media fragment reassembly module 0805 or trigger a back to the origin (pull from device 2), but this should be avoided as much as possible. Usually, the cache window is sufficient to cover user requests.

[0329] The following section explains the data to be cached and the determination of the cache duration in the data processing of devices 2 and 3 during the process of CMAF media fragment (.M4s) to UDP multicast encapsulation and UDP multicast stream to reassemble CMAF media fragment (.M4s).

[0330] In one embodiment, the data caching mechanism of device 2 is as follows: 1. Receive and buffer CMAF media fragments (.M4s): Device 2 obtains CMAF fragments (.m4s files) from upstream (HTTP pull or push). Due to network jitter, the fragments may arrive discontinuously, requiring an input buffer to smooth reception. It is necessary to ensure that the RTP / FU-A fragments are cut into complete CMAF fragments (.m4s files) read by the CMA / RTP packet encapsulation module.

[0331] Caching method: Each channel maintains a circular buffer to store the 1 to 2 most recently received complete fragments.

[0332] Buffer duration: Usually no more than 4 seconds, because the duration of a live stream segment is generally 2 seconds, and buffering 1 to 2 segments can cope with short-term network fluctuations.

[0333] Index: Indexed by the fragment sequence number (such as EXT-X-MEDIA-SEQUENCE) or the sequence number in the fragment URL.

[0334] 2. RTP packet output queue buffer: Device 2 reads the CMAF fragment (.m4s file) from the receive buffer, segments it into RTP payloads using the RTP / FU-A fragmentation mechanism, encapsulates it into CMA / RTP packets, and writes it to the RTP packet output queue buffer. The buffer duration is 1.5 times (2s) the total duration of all RTP packets in one media fragment. 1.5) Cache all RTP packets of a media segment, which can be directly streamed. Once a complete CMAF segment is read from the input buffer, RTP cutting can begin. The cutting process is sequential: read a block of data, add a FU-A header, generate an RTP packet, and then write it to the RTP packet output queue buffer. This zero-copy, pipelined approach reduces latency.

[0335] 3. CMA / RTP packets are encapsulated into UDP packets without buffering, and UDP streams can be sent directly in static multicast mode: The CMA / RTP packet encapsulation module reads RTP packets from the output queue buffer. The network card supports zero-copy and scatter-aggregate, allowing multiple RTP packets to be directly encapsulated into UDP packets for sending without aggregation in memory.

[0336] If the sending rate exceeds the network card's capacity, or if reshaping is required, a sending queue (circular buffer) needs to be added at the driver or application layer. The queue depth is generally no more than 64 packets (about 100KB) to absorb transient bursts.

[0337] 4. Inventory section: After caching, it is retrieved by device 3 via HTTP: Device 2 caches the manifest, which Device 3 actively pulls. After obtaining the original manifest (m3u8 / mpd) from Device 1, Device 2 caches it in memory and marks it with a timestamp and version.

[0338] Device 3 periodically (every 2 seconds) pulls the manifest via HTTP (10G interface). Device 2 returns a cached copy of the manifest, and the cache duration can be controlled by adding a Cache-Control header (e.g., max-age=1).

[0339] Cache duration: The list update cycle (2 seconds) should not be too long, usually 1~2 seconds. It should be used in conjunction with ETag or Last-Modified to implement conditional requests and reduce the amount of data transmitted.

[0340] In one embodiment, the data caching mechanism of device 3 is as follows: 1. After the CMA / RTP / UDP receive and parsing module parses the CMA / RTP packet, it needs to cache the parsed RTP packet itself so that the reassembly module can read and parse the RTP payload.

[0341] Device 3’s 25G network card receives all multicast streams in promiscuous mode. Each RTP packet, once it arrives, needs to be distributed to the corresponding channel’s receive buffer according to the SSRC (Program Identifier).

[0342] Each channel maintains a circular buffer to store the most recently received RTP packets. The buffer size should be able to hold all RTP packets corresponding to at least one complete CMAF fragment (e.g., a 2-second fragment requires approximately 2MB, with the capacity varying depending on the program bitrate).

[0343] Buffer timeout duration: Due to the possibility of out-of-order network packets, it is necessary to wait for all fragmented packets to arrive before reassembling. Therefore, the buffer must retain packets until reassembly is complete or a timeout occurs (e.g., 200ms). If packets are not fully received after the timeout, packet loss processing is triggered.

[0344] 2. How the reorganization module works: The reassembly module reads RTP packets from the receive buffer, sorts them according to sequence number, checks the S / E flag in the FU-A header, and ensures that each fragment has the same timestamp.

[0345] When a fragment start is detected, a reassembly buffer is allocated, and the RTP payload (with header removed) is written sequentially until the E flag is received.

[0346] After the reassembly is complete, the complete CMAF fragment (.m4s file) binary data is obtained, and the fragment can then be handed over to the next cache module for caching.

[0347] 3. Caching mechanism for the reassembled CMAF fragments (.m4s files): The reassembled CMAF fragment (.m4s file) should be written to memory or an SSD cache for file storage. This is to handle client requests, as clients may request the same fragment at different times (e.g., multiple users watching simultaneously).

[0348] Caching strategy: Sliding window, retaining the most recent 60 seconds of clips. Because terminal playback typically has a buffer of tens of seconds, clips older than 60 seconds are rarely requested.

[0349] Index: The filename is used as the index. The filename can contain the channel ID, fragment number, or timestamp, for example, / cache / ch1 / seg_12345.m4s. An in-memory hash table is also maintained to quickly determine if the file exists.

[0350] 4. How to process the list after device 3 retrieves it via HTTP: After device 3 retrieves the list via HTTP, it parses and rewrites the fragment URL to the local cache address (e.g., http: / / device3-IP / cache / ch1 / seg_12345.m4s).

[0351] The rewritten manifest also needs to be cached to respond to terminal requests. The manifest cache time is extremely short (1 second) because the manifest is updated every 2 seconds. Cache for 1 second can reduce the pressure on device 2, while ensuring that the terminal can obtain the new version in a timely manner.

[0352] Association between the inventory and the reassembled fragments: The fragment sequence numbers listed in the inventory should point to files that already exist in memory or SSD cache. If a fragment has not yet been reassembled, device 3 must wait or return to the old inventory (through a delayed update strategy).

[0353] 5. How does the HTTP service module respond to terminal requests? When the terminal requests the manifest, device 3 returns the latest rewritten manifest from its memory cache.

[0354] When the terminal requests a fragment, device 3 searches for the corresponding file in memory or SSD cache based on the URL path. If it exists, it sends it using sendfile with zero copy. If it does not exist, it can retrieve it from the origin device 2, but this will increase latency.

[0355] In one embodiment, CMAF media fragments (.m4s) are synchronized with the HLSm3u8h / DASHmpd manifest to ensure that fragments listed in the manifest requested by the terminal are already available in the cache of device 3 and are time-aligned. Specifically, this may include: 1. Synchronization based on serial number: The EXT-X-MEDIA-SEQUENCE in the list indicates the current fragment sequence number.

[0356] Device 2 can carry the sequence number in the RTP stream through an extended header or a custom method (such as placing the sequence number at the beginning of the RTP payload), and Device 3 records the sequence number of the fragment during reassembly.

[0357] When device 3 generates the manifest, it knows the sequence number of the fragment currently being reassembled, which ensures that the sequence number in the manifest does not precede the actual cache.

[0358] 2. Timestamp-based synchronization: RTP timestamps are related to fragmented PTS, and the EXT-X-PROGRAM-DATE-TIME in the manifest can be mapped to absolute time.

[0359] Device 3 can establish a mapping between RTP timestamps and fragment filenames to ensure that the time information in the manifest is consistent with the cached fragments.

[0360] 3. Cache readiness check: Before generating the inventory, device 3 checks whether the next shard is already in memory or the SSD cache. If it has not yet been reassembled, it can: Wait for a maximum of one segment duration (e.g., 2 seconds). If the timeout occurs, skip the segment (insert #EXT-X-DISCONTINUITY) to avoid playback freezes. Alternatively, revert to the previous version's manifest (extend the cache), but be careful not to violate HLS specifications.

[0361] 4. Fast startup on the first frame: Device 3 pre-caches at least one fragment for each channel (such as the one currently being reassembled). When the terminal makes its first request, this pre-cached fragment is directly included in the manifest without waiting, ensuring that the first frame takes ≤500ms.

[0362] In one embodiment, the data cache lists for device 2 and device 3 can be as shown in Table 14 below: Table 14

[0363] The data processing flow for Device 2 and Device 3 is described below: Equipment 2 processing flow: S1: Receive CMAF fragments from upstream, store them in a circular buffer in memory by channel (indexed by fragment sequence number), and buffer for about 2 seconds.

[0364] S2: The RTP fragmentation module reads a complete fragment from the buffer, performs FU-A splitting directly, generates an RTP packet, and immediately writes it to the RTP packet output queue cache.

[0365] S3: The UDP encapsulation module reads RTP packets from the RTP packet output queue buffer and sends the RTP packets directly through the network card's send queue. The queue depth is very small (<64 packets), so no application layer caching is required.

[0366] S4: The list module periodically pulls the list from the upstream, caches it in memory, and makes it available for device 3 to pull via HTTP.

[0367] S5: The initialization fetch module fetches the initialization fragment when the device boots up or when a new version is available. It is permanently cached within the version and made available for device 3 to fetch via HTTP.

[0368] Equipment 3 processing flow: S1: The network card receives all multicast streams in promiscuous mode and distributes RTP packets to the corresponding channel's receive ring buffer (each channel is independent, with a capacity of 2MB and a waiting time of 200ms) according to the destination IP and port.

[0369] S2: The RTP packet parsing module periodically scans the receive buffer for RTP packets, parses them using a triple mechanism of timestamp, sequence number, and FU-A flag, sorts them by sequence number, and writes them to the reassembly buffer based on the FU-A flag.

[0370] S3: The complete CMAF fragment reading module reads all RTP packet payloads of a complete media fragment from the reassembly cache. After reassembly, the fragment data is written to memory or SSD cache, with the filename containing the channel and sequence number, and the memory index is updated.

[0371] S4: The list retrieval module requests the latest list from device 2 every 1-2 seconds. After receiving the list, it parses it, rewrites the fragment URL to the local path, and then stores the rewritten list in the memory cache (valid for 1 second).

[0372] S5: The initialization pull module pulls the initialization fragment when the system boots up or when a new version is available. It is permanently cached within the version and can be pulled by the terminal via HTTP. It supports pulling.

[0373] The HTTP service module's listening for terminal requests can include: Request list: Reading the latest rewritten list from the memory cache and returning it. Request fragment: Searching for files in the SSD cache based on the URL path; if they exist, they are sent directly; if they do not exist, the request can either go back to the origin device 2 or return to the CMAF media fragment reassembly module 0805.

[0374] Synchronization guarantees may include: Before generating the inventory, Device 3 checks whether the next shard already exists in memory or the SSD cache (through pre-caching or real-time checking). If not, it waits briefly or returns to the old inventory. When all shards are written to memory or the SSD, their RTP timestamps and sequence numbers are recorded and compared with the information in the inventory to ensure consistency.

[0375] Through the above methods, the system can achieve low-latency, high-throughput live streaming distribution, while ensuring accurate synchronization between media segments and lists.

[0376] In one embodiment, the two key caches are described as follows: 1. Receive buffer (RTP packet buffer): Location: Located in the UDP receiver module, immediately after the network card.

[0377] Content: Stores unprocessed RTP packets received from the network. Each channel has its own independent receive buffer.

[0378] Objective: To address network out-of-order delivery and latency jitter. RTP packets may arrive out of order and need to be temporarily stored until all packets belonging to the same CMAF fragment arrive before being handed over to the reassembly module.

[0379] Storage unit: RTP packet (including RTP header, FU-A header, etc.). Each packet is approximately 1400 bytes in size.

[0380] Capacity: The buffer must be able to hold all RTP packets corresponding to at least one complete CMAF fragment. A 2-second CMAF fragment is approximately 2MB in size (assuming a bitrate of 8Mbps). Each RTP packet payload is 1360 bytes, and with the header, the total number of packets is approximately 2MB / 1360 ≈ 1500 packets. Therefore, the receive buffer size needs to be able to store approximately 1500 packets, or approximately 2.1MB (including the header).

[0381] Timeout mechanism: Instead of buffering 200ms of data, it waits 200ms to receive all packets for a fragment. If the last packet does not arrive within 200ms after the first packet of a fragment arrives, the fragment is considered lost, the received packets are cleared, and the upper layer is notified.

[0382] Index: Sort and search by RTP sequence number.

[0383] 2) Reassembly buffer (fragmented cache during reassembly): Location: Located inside the reassembly module, dynamically allocated to each fragment being reassembled.

[0384] Content: Stores the payload data belonging to the same CMAF fragment (i.e., the binary data of the RTP packet after removing the RTP header and FU-A header). This data will eventually be concatenated into a complete .m4s file.

[0385] Objective: To continuously stitch together data that is scattered across multiple RTP packets.

[0386] Storage unit: binary data (without RTP header), size is the same as CMAF fragment (approximately 2MB).

[0387] Lifecycle: Allocation begins upon receiving the first RTP packet (S=1) of a fragment and ends upon receiving the last packet (E=1) and completing the concatenation. If a timeout occurs (no subsequent packets within 200ms), the buffer is released and a packet loss is reported.

[0388] Size: Exactly the size of one CMAF fragment (2MB).

[0389] These two buffers are necessary for layered processing, similar to the socket buffer and application layer buffer in the network protocol stack: The receive buffer addresses the issues of out-of-order delivery and retransmission in network transmission. RTP packets may be retransmitted or out of order in the network, requiring them to be sorted by sequence number first. This buffer operates on a packet-by-packet basis, facilitating packet loss detection and FEC recovery.

[0390] The reassembly buffer addresses the problem of data reassembly. Once it is determined that all packets in a certain fragment are ready (in order), payload data can be continuously written to the reassembly buffer to form a complete file. This buffer operates on a byte stream basis, preparing for subsequent storage.

[0391] If packets are reassembled directly without a receive buffer, gaps will frequently appear in the reassembly buffer when packets are out of order, making management complex and inefficient. Sort packets first, then reassemble them – this is the classic fragment reassembly pattern.

[0392] Regarding the meaning of 200ms: 200ms is not the duration of data caching, but rather a waiting time threshold. It is based on the following considerations: 1) Maximum network latency: In the system, the UDP packet loss rate is ≤1e-6, the network quality is very good, and the normal latency is usually within 10ms. However, in order to prevent rare long latency (such as retransmission or route convergence), a conservative wait time of 200ms is set.

[0393] 2) Low latency target: The first frame requires an end-to-end latency of 500ms, with the internal processing time of device 3 being as short as possible. Waiting too long will slow down the overall performance. 200ms is a compromise, tolerating most network anomalies without causing excessive latency.

[0394] 3) Relationship with fragmentation duration: The fragmentation duration is 2 seconds, but the time window for transmitting these packets over the network is usually within tens of milliseconds (because device 2 sends at line speed, all packets are sent in a very short time (such as a few milliseconds). Therefore, 200ms is sufficient to cover 99.99% of the cases.

[0395] If the last packet does not arrive within 200ms after the first packet of a fragment arrives, the fragment is considered lost. At this time, the packets already received in the receive buffer will be discarded, the reassembly buffer will be released, and then the fragment will be skipped (recovered through FEC or retransmission mechanism).

[0396] The detailed processing steps for device 3 may include: S1: UDP Receive: The network card receives multicast streams and sends RTP packets into the receive buffer (each channel is independent, 2.1MB in size, and can store 1500 packets).

[0397] S2: The receive buffer is sorted by RTP sequence number and records the timestamp of each packet arrival (or the time relative to the first packet).

[0398] S3: Packet Loss Detection: When the first packet (S=1) of a certain fragment arrives, a timer is started with a timeout of 200ms. If the timer expires before the last packet (E=1) of the fragment arrives, all packets related to that fragment are cleared, and a packet loss is reported to the upper layer.

[0399] S4: Fragment Reassembly: When the first packet of a fragment arrives, a reassembly buffer (2MB in size) is allocated. Whenever subsequent packets of that fragment are received (in order), their payload data is written to the reassembly buffer.

[0400] After receiving the last packet (E=1), check if the reassembly buffer is complete (data length is consistent with expectations). If it is complete, the reassembly is complete.

[0401] S5: Storage: After the reconstruction is completed, the binary data in the reconstruction buffer is written to memory or SSD cache file (such as / cache / ch1 / seg_12345.m4s), the memory index is updated, and the reconstruction buffer is released.

[0402] For manifest processing and synchronization: Device 3 periodically (every 2 seconds) pulls the latest manifest from Device 2, rewrites the shard URL to a local path, and stores it in an in-memory manifest cache (valid for 1 second). When generating the manifest, Device 3 checks whether the next shard already exists in memory or on the SSD (e.g., through pre-caching or real-time checking). If it is not ready, it can wait for up to one shard duration (2 seconds), but to meet the 500ms requirement for the first frame, pre-caching is usually used to ensure that the shards listed in the manifest are available.

[0403] For HTTP services: When the terminal requests a manifest, it returns directly from the in-memory manifest cache. When the terminal requests a fragment, the file is read from memory or SSD based on the URL and sent.

[0404] Table 15 below shows the storage content, capacity, lifespan, etc., corresponding to different caches on device 3: Table 15

[0405] The 200ms timeout is the timeout for waiting for all data fragments to be received, not the duration of data buffering. The size of the receive buffer is designed for the entire fragment (1500 packets), not calculated based on a 200ms flow rate. These two buffers work together to achieve low-latency, highly reliable reassembly.

[0406] The following provides a detailed explanation of how to calculate the capacity, duration, and timeout of each buffer stage based on the broadcast-grade standard bitrate.

[0407] Broadcast-grade standards: HD 25Mbps, 4K 36Mbps, 8K 120Mbps, all with a segment duration of 2 seconds. Determine the specific values ​​for each buffer stage.

[0408] Equipment 2: CMAF Media Fragment Caching: Media fragments pulled from upstream and metadata in the HTTP response headers are cached together in preparation for RTP fragmentation; RTP packet output queue buffer: The media segments are divided into small segments of 1360-byte RTP payload using the FU-A standard, and RTP packets are encapsulated with timestamp (pulled from upstream), sequence number and FU-A identifier (generated locally) written in the header. List proxy cache (caches the original list for device 3 to pull); Equipment 3: 1. RTP packet receive buffer: After receiving a UDP packet, the parsed RTP packet is buffered and awaited reassembly; 2. Fragment Reassembly Cache: After parsing the RTP payload, according to the FU-A identifier, timestamp, and sequence number of the RTP packet, the payload of all RTP packets is cached in the reassembly cache; the RTP payload cache in the process of reassembly (RTP payload data of CMAF fragments that are being reassembled). 3. Complete fragment cache (memory or SSD cache) and rewrite manifest cache (memory) after reorganization.

[0409] Determine the following for each cache: Cache duration: How long data is retained in the cache.

[0410] Cache capacity: The size of the cache space.

[0411] Timeout: The time spent waiting for data to be complete or for an operation to be performed.

[0412] It needs to be calculated by combining the bitrate and the segment duration.

[0413] The given conditions are: HD: 25 Mbps, 4K: 36 Mbps, 8K: 120 Mbps.

[0414] Segment duration: 2 seconds.

[0415] Calculate the size of each fragment: Slice size = bitrate Duration / 8 (converted to bytes); High Definition: 25Mbps 2 seconds = 50 Mbits = 50 / 8 = 6.25 MB; 4K: 36Mbps 2 seconds = 72 Mbits = 9 MB; 8K: 120Mbps 2 seconds = 240 Mbits = 30 MB.

[0416] The design of each cache needs to be determined.

[0417] Device 2 cache settings: 1.1 CMAF Fragmented Cache: Function: After the CMAF media fragment (.m4s) pull module 0602 of device 2 pulls the media fragment from the upstream, it may need to cache several fragments due to network jitter to ensure that the RTP fragment module has data available, and at the same time cope with the short-term delay of the upstream.

[0418] Cache duration: Typically, a small number of media segments are cached, such as 2-3 segments, to handle brief network fluctuations. If a media segment duration is 2 seconds, caching 3 segments would take 6 seconds. However, considering real-time requirements, caching 1-2 segments is usually sufficient. At the broadcast level, a smoother experience may be desired, and caching 3 segments (6 seconds) is also reasonable.

[0419] Capacity: A maximum of N fragments need to be cached for each channel. Assuming device 2 supports simultaneous processing of 198 channels, the number of fragments required per channel is as follows: If 2 fragments are cached, and each fragment size is the maximum (8K 30MB), then each channel requires 60MB, and 198 channels would require approximately 11.88 GB. If high-definition is the primary focus, the requirement is smaller. However, the design should be based on the highest bitrate, as device 2 may simultaneously process 8K streams from all channels. In a broadcast environment, not all channels may be 8K, but for safety, the maximum value is used in the design. However, the actual deployment may be configured according to the actual bitrate. It is recommended to design based on the highest bitrate and consider caching 2 fragments, resulting in a cache capacity of 2 per channel. 30MB = 60MB, 198 channels approximately 11.88 GB, plus some overhead, 12-16 GB of memory can be allocated as CMAF fragment cache for device 2.

[0420] Timeout: When fetching shards from upstream, a timeout will occur if the fetching fails or is delayed. This timeout typically depends on the shard duration; for example, if the next shard is not received within the shard duration, an alarm may be triggered or degradation measures may be taken. However, the cache's own timeout refers to the lifespan of data in the cache, generally based on a sliding window. Shards that exceed the cache duration are evicted. Here, the cache duration is the retention time of the shard. For example, if two shards are cached, the oldest shard will be overwritten by the newest shard after two shards (4 seconds). Therefore, timeouts are automatically managed by a sliding window.

[0421] 1.2 RTP packet output queue buffer: Function: The CMA / RTP encapsulation module 0604 of device 2 reads the media fragment (.m4s) file from the circular buffer, divides the media fragment into small fragments of 1360 bytes of RTP payload using the FU-A standard, and encapsulates the RTP packet. The header of the packet contains a timestamp (pulled from upstream), a sequence number, and an FU-A identifier (generated locally). Each generated RTP packet is then pushed into the corresponding channel's transmission queue circular buffer. Capacity: (Each channel has a circular buffer, and the recommended capacity is 1.5 times the maximum number of fragment packets. For example, 8K fragments are about 23,000 packets, so the queue size is about 35,000 packets, or about 52MB / channel). Module 0604 does not send directly, but is only responsible for writing RTP packets into the sending queue of each channel in order. Timeout: Circular cache, when the capacity is full, the most advanced cached data is aged out; 1.3 Inventory Proxy Caching: Function: Caches the raw manifest obtained from upstream for device 3 to pull. The manifest is usually small and is updated every 2 seconds.

[0422] Cache Duration: The manifest needs to be updated promptly, but there may be a slight delay in device 3's fetching. Generally, cache 1-2 manifest versions for 1-2 seconds. A 1-second cache is recommended because the manifest updates every 2 seconds; a 1-second cache reduces the load on device 2 while ensuring device 3 can obtain the latest version promptly. Conditional requests (ETag) can also be used to avoid duplicate transmissions.

[0423] Size: List size is generally tens of KB. With 198 channels caching 1-2 lists at the same time, the total capacity is very small, tens of MB is sufficient.

[0424] Timeout: The manifest cache can be set to expire, such as 1 second, and then it will be fetched again after the expiration.

[0425] Device 3 cache settings: 1.1 RTP packet receive buffer: Function: To receive multicast RTP packets. Because network packets may be out of order, they need to be temporarily stored and awaited reassembly. This buffer is an independent circular buffer for each channel, storing received RTP packets (including RTP headers and payloads).

[0426] Cache duration: Not based on time, but on the number of packets or the time to wait for reassembly to complete. It's typically designed to hold all RTP packets for at least one complete fragment, as it requires waiting for all packets to arrive and be read. However, considering network latency, a timeout can be set, such as waiting 200ms from the receipt of the first packet. If not all packets are received within 200ms, the fragment is considered lost, and related packets are cleared.

[0427] Capacity: This refers to the number of RTP packets that can be accommodated for a complete fragment. The size of a fragment varies depending on the bitrate; the number of RTP packets = fragment size / RTP payload size. The RTP payload size is typically 136 bytes. Calculation: High Definition: 6.25 MB = 6.25 124 124 = 6,553.6 bytes, divided by 136 ≈ 4818 packets.

[0428] 4K: 9 MB = 9 124 124 = 9,437,184 bytes, divided by 136 ≈ 694 packets.

[0429] 8K: 3 MB = 3 124 124 = 31,457,28 bytes, divided by 136 ≈ 2313 packets.

[0430] Each packet contains an RTP header (12 bytes) and a FU-A header (2 bytes), etc. The receive buffer stores the complete RTP packet (including the header), and each packet is approximately 14 bytes in size (the UDP / IP header may be stripped at the network interface card layer, but the application layer receives the RTP packet, which usually does not include the link layer header, so it is approximately 14 bytes). Therefore, the storage space for each packet is approximately 14 bytes. For 8K, 2313 packets need to be stored, and the buffer size = 2313. 14 ≈ 32.4 MB. For HD, approximately 4818 14 ≈ 6.75MB. Therefore, to support 8K, each channel's RTP receive buffer needs approximately 33 MB. If device 3 needs to handle 198 channels simultaneously, it might only serve a portion of the users, but it receives all multicast streams because it needs to serve users on all channels. Therefore, device 3 needs to be able to receive multicast from all 198 channels, but the receive buffer for each channel is independent. If simultaneously receiving 198 channels of 8K streams, with 33 MB per channel, the total buffer requirement = 198 33 MB ≈ 6.5 GB. This memory requirement is feasible, but requires a large amount of memory. In actual deployment, 8K channels may be less common, but system scalability should be considered in the design. Memory can be reserved according to maximum demand, or dynamic allocation can be used.

[0431] Timeout: Each fragment has a reassembly timeout, such as 200ms. If all packets for a fragment are not received within 200ms from the receipt of the first packet, the packets associated with that fragment are cleared (possibly discarded or triggering FEC / retransmission). This timeout is time-based and independent of bitrate because network latency is fixed (the timeout may be adjusted based on actual network conditions).

[0432] 1.2 RTP payload cache during reassembly: Function: When RTP packets are reassembled in order, the payload data needs to be stored contiguously to form complete CMAF fragments. This is a temporary buffer, one of which is allocated to each channel being reassembled, with a size equal to the size of a fragment. Once the fragment reassembly is complete, this buffer is released or used for the next fragment.

[0433] Cache duration: from the start of reassembly to its completion, generally less than 200ms (because it needs to wait for all packets). If a timeout (200ms) occurs, the packet is discarded.

[0434] Capacity: The buffer needs to be large enough to store the payload data of a complete fragment, equal to the fragment size (excluding the RTP header). For 8K, this is 30 MB. Therefore, each concurrently reassembled fragment requires 30 MB. Since only one fragment is being reassembled per channel (due to sequential reassembly), each channel requires a 30 MB buffer. Simultaneous reassembly of 198 channels requires 198... 30 MB = 5.94 GB. Adding the RTP packet receive cache, the total memory is approximately 12.5 GB. Including other overhead, Device 3 requires at least 16-32 GB of memory; the previously recommended 512 GB was more than sufficient.

[0435] Timeout: Recombination timeout, 200ms.

[0436] 1.3. Complete fragmented cache after reorganization: Purpose: To store reassembled CMAF fragments for subsequent HTTP services. A sliding window is used to retain fragments from the most recent period so they can be directly provided when a user requests them.

[0437] Cache duration: To support user time-shifting and cope with network fluctuations, caching is typically from tens of seconds to several minutes. Previously, we discussed 60 seconds. For 8K, 60 seconds requires caching 30 segments (one every 2 seconds), each 30 MB, totaling 900 MB. For HD, 60 seconds requires 30... 6.25 MB = 187.5 MB. If there are multiple channels simultaneously, each with independent caching, the total SSD requirement = number of channels. Single-channel cache capacity. If all 198 channels are 8K, then the SSD requirement = 198. 900 MB ≈ 178.2 GB. For mixed bitrates, you can estimate based on the average value. It's recommended to plan based on the highest bitrate, but the actual configuration can be adjusted as needed. This part has the largest cache capacity, so you need to consider channel switching time and cost factors to determine whether to use memory or SSD caching entirely.

[0438] Timeout: Based on a sliding window, segments that exceed 60 seconds are automatically deleted.

[0439] 1.4 Rewrite the manifest cache: Function: Caches the rewritten manifest for terminal requests.

[0440] Cache duration: The manifest is updated every 2 seconds, and the cache duration is about 1 second to ensure real-time performance.

[0441] Size: The list is very small, with 198 channels and a 1-second buffer for each list, resulting in a small total size of a few MB.

[0442] 1.5 Initialize the sharded cache: It is fetched when the device starts up or initializes a fragment version update, permanently cached within the version, and actively updated when the version is updated. The total size is very small, only a few hundred MB.

[0443] The caching details for Device 2 and Device 3 are shown in Table 16 below: Table 16

[0444] The above capacity calculations are based on the extreme case of all channels being 8K 120Mbps. In actual deployments, a mixed configuration can be used depending on the channel type, but the hardware should reserve expansion space. Additionally, the RTP packet receive buffer and reassembly payload buffer are in memory, totaling approximately 12.5 GB. Including other overhead, a memory configuration of 16-32 GB is sufficient for Device 3. The media fragmentation buffer capacity is approximately 178 GB; considering cost and first frame time, 240 GB of memory or SSD caching can be used.

[0445] The cache timeout (200ms) is set based on network latency and low-latency goals, and is independent of bitrate. A 200ms timeout for fragment reassembly is reasonable because with good network quality, most packets will arrive within tens of milliseconds.

[0446] However, it is worth noting that the above values ​​should be determined based on actual testing. In actual implementation, they can be adjusted as needed, and this application does not impose any restrictions.

[0447] Based on broadcast-grade bitrates (HD 25Mbps, 4K 36Mbps, 8K 120Mbps) and segment durations of 2 seconds, the parameters for each buffer stage of device 2 are shown in Table 17 below, and the parameters for each buffer stage of device 3 are shown in Table 18 below: Table 17

[0448] Table 18

[0449] That is, all capacities are calculated based on the extreme case of 8K. In actual deployment, they can be adjusted according to the mixed bitrate of the channels, but the hardware should reserve expansion space. Both the RTP packet receive buffer and the reassembly payload buffer are memory buffers, totaling approximately 12.5GB. Including operating system overhead, it is recommended that device 3 have ≥32GB of memory. SSD caching: 178GB is the caching requirement for 198 8K channels for 60 seconds. Actual SSD capacity can be 240GB / 480GB, or larger, to support longer time-shift windows. 200ms timeout: Set based on network quality (packet loss rate ≤1e-6) and low latency target to ensure it does not affect the 500ms first frame target. This can be fine-tuned in practice. CMAF fragment caching on device 2: Cache 2 fragments to smooth out short-term upstream jitter. If upstream reliability is high, this can be reduced to 1 fragment (30MB / channel).

[0450] In one embodiment, the input of the media stream encapsulation gateway device 1 is not limited to TS / RTP multicast streams. It can be the video NALUs and audio frames of the ES stream output by the encoding cluster of the live streaming service platform, or the PES stream, or the CMAF media segments directly output by the encoder. However, considering standardization and seamless integration with existing platforms, receiving TS / RTP multicast streams should be the primary approach.

[0451] The following is a comparative analysis of the advantages of investment and operating costs using a specific example: The method for transmitting live broadcast television services based on streaming media protocols proposed in this disclosure aims to provide users with live streaming services that are compatible with smart terminals, fundamentally solving the problem of insufficient compatibility of DVB broadcast, IP broadcast, and live broadcast services using the IGMP protocol with home networks and smart terminals.

[0452] In terms of simply providing users with live streaming services based on streaming media protocols, the OTT solution fully meets the compatibility issues of user terminals. However, the difference lies in the fact that the OTT solution incurs significantly higher costs for backbone network bandwidth and CDN node investment than the method for transmitting live broadcast television services based on streaming media protocols proposed in this disclosure. Moreover, its transmission quality is unlikely to meet the transmission indicators of live broadcast television services.

[0453] Suppose there are two options, A and B, where: Option A: The protocol conversion system and method for transmitting live broadcast television services based on streaming media protocols proposed in this example convert the original HLS / DASH media stream live service into a low-latency UDP multicast stream for transmission to the access network central office. The transmission bandwidth within the core network is independent of the concurrency rate of access users and is a constant bandwidth for the broadcast program to be transmitted, significantly saving core network transmission bandwidth. Moreover, the investment cost of multicast relay equipment is far lower than the investment cost of CDN nodes in OTT solutions. Option B: The original HLS / DASH media stream live service on the platform side is transmitted to the access network user end through a source-end CDN and edge CDN transmission scheme in the core network and access network. A large number of CDN nodes and transmission bandwidth capable of supporting high concurrency are built in the core network and metropolitan area network.

[0454] Assuming that the investment in platform-side, core network, and access network equipment is the same for both schemes A and B (in reality, the investment cost of core network equipment for scheme A is actually less than that for scheme B), and only comparing the investment cost in core network bandwidth, scheme A has a clear advantage.

[0455] To indirectly determine the operational cost advantages of the two methods, a comparison can be made based on the method of leasing bandwidth: Assuming a user base of 5 million users, and a concurrency rate of 60% for a specific scenario in the live streaming business, the number of concurrent users would be 5 million × 60% = 3 million users.

[0456] Bandwidth model: Assuming an average bitrate of 10Mbps for programs (taking into account future HD and 4K / 8K programs as well as broadcast-grade transmission).

[0457] I. Investment estimate for core network bandwidth requirements in Option B (traditional CDN mode): 3 million concurrent users × 10 Mbps = 30 Tbps (30,000 Gbps). If 30% of this 30 Tbps is allocated to core network computing (considering the storage function of edge nodes for popular streams), it would also occupy nearly 10 Tbps of core network transmission bandwidth.

[0458] II. Investment estimate for core network bandwidth requirements under Option A (Multicast Mode): In static multicast mode, the core network bandwidth is only used to transmit the traffic of the program channels, and is unrelated to the number of concurrent users. Assume 198 programs with an average bitrate of 10Mbps.

[0459] Core network multicast bandwidth = 198 × 10 Mbps = 1.98 Gbps (actually approximately 2 Gbps). Estimated core network list and initial fragmentation bandwidth: calculated at 1 Gbps, total bandwidth is 3 Gbps.

[0460] Because the platform connects to multiple access network gateways at the access network end, and considering that the core network to the access network end can have tree, ring, and star topology physical routes, the total transmission bandwidth can be recorded as 1T.

[0461] III. Bandwidth Costs (Annualized Comparison): Bandwidth is calculated based on lease: Assuming operation for 3 years, the core network bandwidth cost is calculated at 5 yuan / Mbps / month: Plan B (CDN) annual bandwidth fee: Peak bandwidth: 10,000 Gbps = 10,000,000 Mbps Monthly fee = 10,000,000 × 5 yuan / month = 50 million yuan / month Annual fee = 600 million yuan; Plan A (Multicast) Annual Bandwidth Fee: Core network bandwidth: 1000Gbps = 1000,000 Mbps Monthly fee = 1,000,000 × 5 = 5 million yuan / month Annual fee = 60 million yuan.

[0462] Comparison of bandwidth costs over 3 years: Option B: 600 million × 3 = 1.8 billion yuan.

[0463] Option A: 60 million × 3 = 180 million yuan.

[0464] Therefore, for a network with 5 million users, the long-term economic benefits of multicast far outweigh those of CDN. Even assuming that the initial investment for a multicast solution is higher than that for an OTT solution, its lower operating costs result in annual bandwidth savings of hundreds of millions of yuan after the initial investment is recouped.

[0465] In the above comparison, the core network bandwidth of schemes A and B is calculated based on leasing. If both are calculated based on new construction investment, the investment of scheme B will be much greater than that of scheme A, and the annual operating cost of the bandwidth will still be greater than that of scheme A.

[0466] In terms of content transmission, both A and B provide users with HLS / DASH media streaming live services, and their compatibility with home networks and terminals is the same. However, solution A uses a multicast protocol in the core network to transmit HLS / DASH media streaming live services. Although it transmits HLS / DASH media streams, its transmission quality is broadcast-grade. In the transmission of high-definition, ultra-high-definition 4K, and 8K programs, solution B not only consumes a large amount of core network transmission bandwidth when the concurrency rate is high, but its channel switching time may also be more than 2 seconds. In contrast, the solution A disclosed in this paper can achieve less than 500ms.

[0467] In one embodiment, the proposed method for transmitting live broadcast television services based on streaming media protocols, compared to current IPTV systems, requires multiple replication points of multicast routers supporting the IGMP protocol from the platform side to the user terminal. Furthermore, the bandwidth consumption of the core network and access network is 30%-40% higher than this solution. Additionally, because home routers' NAT mechanisms are not conducive to dynamic multicast, and most televisions do not support dynamic multicast, the user end must be equipped with a dedicated operator gateway and a dedicated decoding gateway. Therefore, the overall investment and operating cost of the IPTV system's core network is higher than the protocol conversion system and the proposed method for transmitting live broadcast television services based on streaming media protocols. Moreover, the packet loss rate of the IPTV system is significantly greater than 10%. -6 However, the transmission performance of high-definition, ultra-high-definition 4K, and 8K programs is difficult to reach broadcast-grade transmission standards.

[0468] In one embodiment, the method for transmitting live broadcast television services based on streaming media protocols proposed in this disclosure, compared with current cable television network IP broadcast systems and DVB broadcast systems, although the core network investment cost and access network central office investment cost of current cable television network IP broadcast systems and DVB broadcast systems are lower than the solution of this disclosure, the cost of accessing households is higher, thus the overall investment cost is higher than the investment cost of this solution. Specifically: IP broadcasting and DVB broadcasting systems are completely incompatible with home routers and smart terminals. Moreover, their broadband and broadcasting services must enter the home through separate channels, which is equivalent to superimposing a one-way broadcast access network on a two-way access network. At the same time, users must be equipped with an in-home gateway and a dedicated decoder, making the cost of accessing the network to the home extremely high. Furthermore, with the increasing demand for standard definition to high definition, high definition to ultra-high definition 4K, and 8K programs, their decoding terminals are constantly being upgraded, leading to more repetitive investments.

[0469] However, the protocol conversion system and method for transmitting live broadcast television services based on streaming media protocols proposed in this disclosure use the HTTP protocol based on the TCP / IP protocol for home access. Broadband services and broadcast services share a single access network, and the broadcast service is based on the HTTP protocol transmission mechanism, which is fully compatible with the access of user-end home routers, smart TVs, and other smart terminals. The user end does not need to be equipped with a dedicated gateway and a dedicated decoder. The cost of home access is far lower than that of IP broadcast and DVB broadcast systems that require a dedicated channel for broadcast services and are equipped with a dedicated gateway and a dedicated decoder. Moreover, it does not incur duplicate investment costs.

[0470] Meanwhile, this application provides a method for transmitting live broadcast television services based on streaming media protocols. The platform-side protocol converter converts the original HLS / DASH media stream live service into a low-latency UDP multicast stream and transmits it to the access network office. The access network office protocol converter then converts the UDP multicast stream back into the original HLS / DASH media stream live service and transmits it to the user terminal through the access network. Mobile phones, computers, and smart TVs with HLS / DASH streaming media playback capabilities and system apps installed can receive and play the media stream protocol live service through a home router, fundamentally solving the problem of insufficient compatibility of UDP multicast or IP broadcast live services with home networks and smart terminals.

[0471] In one embodiment, the protocol conversion system and method for transmitting live broadcast television services based on streaming media protocols disclosed herein can fully utilize existing core network and access network resources, while also sharing the existing CENC standard encryption and key management front-end platform managed by the DRM system. This provides users with converged service offerings of broadband Internet services, communication services, video-on-demand services, and live broadcast television services, and provides operators with access networks that offer low investment costs, high transmission efficiency, less redundant investment, and high return on investment.

[0472] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, hardware + program embodiments are relatively simple in description because they are fundamentally similar to method embodiments; relevant parts can be referred to the descriptions in the method embodiments.

[0473] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0474] While this application provides the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0475] While this specification provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0476] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing the embodiments of this specification, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0477] Those skilled in the art will also know that, besides implementing the controller using purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the controller function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices within it used to implement various functions can also be considered structures within that hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the method and structures within a hardware component.

[0478] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0479] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of computer program products implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0480] The embodiments described in this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0481] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments in this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0482] The above description is merely an embodiment of the present specification and is not intended to limit the embodiments of the present specification. For those skilled in the art, various modifications and variations can be made to the embodiments of the present specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of the present specification should be included within the scope of the claims of the embodiments of the present specification.

Claims

1. A system for transmitting live broadcast television services based on streaming media protocols, characterized in that, include: The platform-side media stream encapsulation gateway is used to receive TS / RTP multicast streams from the platform side, convert them into media fragments, initialize the fragments and manifest files, and then connect them to the platform-side media stream multicast gateway. The platform-side media stream multicast gateway is used to transmit the initial fragmentation and manifest file to the access network office through the core network HTTP channel, and to convert and encapsulate the media fragmentation into a CMA / RTP multicast stream, and then transmit it to the access network office through the core network in multicast relay mode. The core network multicast service relay transmission system is used to transmit CMA / RTP multicast streams to the access network central office streaming media encapsulation gateway in multicast relay mode. The access network central office streaming media reassembly gateway is used to receive CMA / RTP multicast streams transmitted from the platform side to the access network central office through the core network multicast relay mode and reassemble media fragments. At the same time, it receives the manifest file and initial fragments corresponding to the media fragments through the HTTP channel, rewrites the manifest file, and after synchronizing the media fragments and manifest file, it connects the initial fragments, manifest file and media fragments to the access network central office integrated service gateway. The access network central office integrated service gateway is used to provide DHCP services to user-end home routers, while providing integrated service services such as aggregation and routing forwarding for the original system's communication services, broadband services, and live streaming protocol output by the access network central office streaming media reassembly gateway; The access network from the access network office to the user end provides Layer 2 forwarding and optical or copper cable access carrier between the integrated service gateway at the access network office and the CPN network at the user end, and is used for integrated access of broadband services, communication services and live broadcast television streaming services from the integrated service gateway to the home CPN network. The user-side CPN network includes home routers and user terminals connected to the home routers, used to access user-side terminal devices to achieve integrated service access.

2. The broadcast television live broadcast service system based on streaming media protocol according to claim 1, characterized in that, The platform-side media stream encapsulation gateway includes: a TS / RTP packet receiving engine module, a cache management module, a TS packet demultiplexing and PES packet reassembly module, a PES packet parsing module, a CENC standard encryption module, a CMAF streaming media segmentation and encapsulation module, an initialization segmentation and encapsulation module, a CMAF streaming media segment writing module, a manifest file generation module, a first HTTP service module, and a second HTTP service module, wherein: The TS / RTP packet receiving engine module is used to receive the TS / RTP multicast stream output by the platform-side encoding cluster, and parse the TS / RTP packets or TS packets from the TS / RTP multicast stream. The TS / RTP packets or TS packets are then cached in the TS / RTP packet or TS packet cache area of ​​the cache management module so that the TS packets can be demultiplexed and read by the PES packet reassembly module. The TS packet demultiplexing module is used to read the TS / RTP packets or TS packets in the TS packet cache area of ​​the cache management module, and parse, demultiplex and reassemble the TS / RTP packets or TS packets to generate PES packets. The PES packets are then cached in the PES packet cache area of ​​the cache management module so that the PES packet parsing module can read them. The PES packet parsing module is used to read PES packets from the PES packet buffer of the cache management module, parse the access units composed of video NALU series and audio frames of the ES stream from the PES packets, perform sample processing on the access units to obtain clear stream samples, extract the sample-level metadata and encoding parameters of the clear stream samples, and write the display timestamp, decoding timestamp, frame type, sample size, access unit boundary flag and encoding parameters of the clear stream samples and sample-level metadata into the clear stream sample, sample metadata and encoding parameter buffer of the cache management module respectively; The CENC standard encryption module is used to read the clear stream sample and perform CENC standard encryption on the payload of the clear stream sample to obtain an encrypted sample. The encrypted sample is written into the encrypted sample cache area of ​​the cache management module. At the same time, the DRM encryption information metadata generated in the CENC standard encryption process is output and cached in the DRM encryption information metadata cache area of ​​the cache management module. The DRM encryption information metadata includes: initialization vector, encryption flag, encryption byte range, sample encryption information that can be loaded into the moof box part of the CMAF media segment, and default key ID, protection system specific header, SystemID, license access address, default IV size, encryption mode, and DRM system identifier that can be loaded into the moof box part of the initialization segment, so that the CMAF streaming media segment encapsulation module and the initialization segment encapsulation module can read it. The CMAF streaming media segment encapsulation module is used to read encrypted samples from the encrypted sample cache area of ​​the cache management module, while reading sample metadata from the PES packet sample metadata cache and DRM encrypted information metadata from the DRM encrypted information metadata cache. It encapsulates the samples into CMAF streaming media segments in units of closed GOPs with a duration of 2 seconds set by the encoder, and writes the CMAF streaming media segments into the media segment temporary cache area of ​​the cache management module so that the CMAF media segment writing module can read them. At the same time, it generates segment-level metadata of the CMAF streaming media segments based on the sample-level metadata of the CMAF streaming media segments and writes it into the segment-level metadata cache area of ​​the cache management module. The CMAF streaming media segment writing module is used to read the CMAF streaming media segments from the media segment temporary buffer of the cache management module and write them into the media segment publishing buffer of the cache management module. The initialization segment encapsulation module is used to read the encoding parameters in the encoding parameter cache and the metadata of the encrypted information in the DRM encryption information metadata cache and load them into the moov box. Based on the encoding parameters and DRM encryption information metadata, it encapsulates the initial segments required for media segment decoding and writes the initial segments into the initial segment cache of the cache management module. At the same time, it generates initial segment metadata based on the initial segments and writes it into the segment-level metadata cache of the cache management module. The manifest file generation module is used to read CMAF streaming media segment metadata and initialization segment metadata from the segment-level metadata cache area of ​​the cache management module, generate the HLSm3u8h / DASHmpd manifest corresponding to the CMAF media segment based on the CMAF streaming media segment metadata and initialization segment metadata, and write it into the manifest cache area of ​​the cache management module. The first HTTP service module provides an interface for the platform-side streaming media multicast gateway to pull CMAF streaming media segments, enabling protocol conversion from CMAF streaming media segments to CMA / RTP multicast. Simultaneously, when returning the pulled media segments, it writes the segment's start timestamp (PTS) into the HTTP header. It transmits the media segments and metadata using out-of-band metadata and a black-box data transmission mechanism. This allows the platform-side streaming media multicast gateway to obtain the PTS of a segment from the HTTP header without parsing the segment in the black box during the protocol conversion from RTP FU-A segmentation to CMA / RTP packets. The PTS is then written into the header of all CMA / RTP packets after the segment is cut, ensuring that all RTP packets of each media segment have the same timestamp, thus determining the attribution of CMA / RTP packets with the same timestamp to a single media segment. The second HTTP service module is used to provide the platform-side streaming media multicast gateway with a pull interface for retrieving the CMAF streaming media segment manifest file and initializing segments.

3. The broadcast television live broadcast service system based on streaming media protocol according to claim 1, characterized in that, The platform-side media stream multicast gateway includes: a CMAF fragment retrieval module, a cache management module, a CMA / RTP packet encapsulation module, a fragment initialization and manifest file retrieval module, a CMA / RTP multicast stream encapsulation module, and an HTTP service module, wherein: The CMAF segment retrieval module is used to retrieve CMAF media segments encapsulated and output by the platform-side media stream encapsulation gateway after scrambling according to the CENC standard via the HTTP interface. The retrieved media segments and the IDR frame timestamp (PTS) in the HTTP header are written to the media segment circular buffer and the PTS buffer, respectively, so that the CMA / RTP encapsulation module can read the media segments and the PTS of the IDR frame of the segment. The CMA / RTP packet encapsulation module reads complete CMAF media segments from the media segment circular buffer. It does not parse the media segments but treats them as binary black boxes to implement RTP FU-A binary segmentation. The segment size follows the TCP / IP protocol MTU value specification. Each media segment is divided into multiple RTP packet payloads and encapsulated into RTP packets. Simultaneously, it reads the timestamp (PTS) of the segment's IDR frame from the PTS buffer and injects a triple identifier (PTS, sequence number, and FU-A identifier) ​​into the header of the segmented and encapsulated RTP packets. This ensures that all RTP packets from the same media segment have the same timestamp, incrementing sequence numbers, and the FU-A identifier identifies the start and end of each CMAF media segment RTP packet. After CMA / RTP packet encapsulation, the packets are written to the CMA / RTP packet output queue buffer for buffering. The initialization fragment and manifest file retrieval module is used to retrieve the m3u8h / mpd manifest provided by the platform-side media stream encapsulation gateway via the HTTP channel, store it in the manifest cache, proxy it and provide it to the access network's streaming media reassembly gateway for retrieval. At the same time, it is also used to retrieve the initial fragments provided by the platform-side media stream encapsulation gateway and store them in the initialization fragment permanent cache. The CMA / RTP multicast stream encapsulation module is used to read media fragment CMA / RTP packets from the CMA / RTP packet output queue buffer, encapsulate them into CMA / RTP / UDP multicast streams, and then connect them to the core network multicast service relay transmission system. The core network multicast service relay transmission system then transmits the platform-side CMA / RTP / UDP multicast streams to the access network central office streaming media reassembly gateway. The HTTP service module provides an HTTP service interface for media manifests and initial fragments, enabling the access network's streaming media reassembly gateway to pull the m3u8h / mpd manifest and initialize fragments via HTTP service.

4. The broadcast television live broadcast service system based on streaming media protocol according to claim 1, characterized in that, The access network central office streaming media reassembly gateway includes: a CMA / RTP multicast stream to CMA / RTP layer parsing module, a cache management module, a CMA / RTP packet parsing module, a CMAF media fragment reassembly module, a manifest and initial fragment retrieval module, and a CMAF media fragment / manifest file / initial fragment HTTP service module, wherein: The CMA / RTP multicast stream is sent to the CMA / RTP layer parsing module, which receives the CMA / RTP multicast stream transmitted from the platform-side media stream multicast gateway through the core network multicast service relay system, parses out the CMA / RTP packets of the CMA / RTP multicast stream, and writes them into the CMA / RTP packet buffer area of ​​the cache management module for caching, so that the CMA / RTP packet parsing module can read and parse them. The CMA / RTP packet parsing module is used to read the CMA / RTP packets cached in the CMA / RTP packet cache area, parse out the RTP FU-A fragments of the RTP packet payload, and write them into the RTP FU-A fragment reassembly cache area according to the triple identifier of timestamp, sequence number and FU-A. The reassembly cache follows the triple identifier to ensure that the timestamp of the RTP packets of the same media fragment is the same, the sequence number is incremented, and the FU-A identifier determines the start and end of the fragment RTP packet. After all the RTP FU-A fragments of a media fragment are cached, the CMAF media fragment reassembly module is notified to read them. The CMAF media fragment reassembly module is used to read the CMA / RTP packet payload written to the reassembly buffer by the CMA / RTP packet parsing module. The reassembly buffer is a double buffer. When writing to one buffer, the RTP packet payload of the previous fragment is read from the other buffer. Writing and reading do not affect each other. Reading all the RTP packet payloads of a media fragment can reassemble a CMAF media fragment and write it to the CMAF media fragment circular buffer. The manifest and initial segment retrieval module is used to retrieve the m3u8h / mpd manifest and rewrite the media stream URL in the manifest. The URL points to the streaming media reassembly gateway to realize the synchronization of the media stream and manifest and store it in the manifest cache. At the same time, it retrieves the initial segments and stores them in the initial segment cache, so that the user terminal can retrieve the initial segments, m3u8h / mpd manifest and media segments. The CMAF Media Segmentation / Manifest File / Initialized Segmentation HTTP Service module is used to provide user terminals with the service of pulling media stream segments / initialized segments / media stream manifests by path. According to the user's request, it reads media stream segments / initialized segments / media stream manifests from the media segment cache, the initialized segment cache, and the manifest cache and forwards them to the user. Initialized segments support pre-fetching and random fetching services.

5. The broadcast television live broadcast service system based on streaming media protocol according to claim 1, characterized in that, The integrated service gateway includes: a high-speed interface and forwarding engine, a DHCP service module, a service identification and traffic distribution module, a policy control and QoS module, a session and resource management module, a configuration management module, a monitoring and alarm module, and a security and logging module, wherein: The high-speed interface and forwarding engine provide multiple 100G and multiple 10G high-speed northbound interfaces for accessing the original system BRAS, management platform, network management system, and access network central office streaming media reassembly gateway. These interfaces enable line-speed packet forwarding and system management. A 100G high-speed interface is provided to the original system BRAS to ensure access and forwarding of broadband, communication, and video-on-demand services. A 100G high-speed interface is also provided to the access network central office streaming media reassembly gateway to ensure access and forwarding of live streaming media protocols encapsulated and output by the gateway. The 10G interface can connect to the service management platform and network management system. 24 / 48 access is provided on the user side. 25G / 40G southbound interfaces, used to access 24 / 48 25G / 40G+48 The 1G / 10G interface access switch connects to the CPN network at the user end, which uses the home router as the gateway, to achieve converged access of broadband services, communication services, and streaming media protocol broadcast services. The DHCP service module is used to provide DHCP relay or DHCP service functions. In DHCP relay mode, the allocation and management of user terminal IP addresses are managed by the original system BRAS. In DHCP service mode, the DHCP service function of the original system BRAS is moved down to the integrated service gateway to provide DHCP service functions. The service identification and traffic splitting module is used to ensure that the original system's broadband and communication services are forwarded along the original path in DHCP relay mode, while enabling the newly added streaming media protocol live broadcast services to be forwarded locally without going through the original system's BRAS. The policy control and QoS module works in conjunction with the service identification and traffic splitting module to ensure local forwarding of streaming media protocol live services with high bandwidth and long connection characteristics through policy routing. The Session and Resource Management module, Configuration Management module, Monitoring and Alarm module, and Security and Log module are used to implement resource management, configuration management, log management, and security monitoring of the integrated gateway, providing control layer and management layer functions.

6. The broadcast television live broadcast service system based on streaming media protocol according to claim 2, characterized in that, The out-of-band metadata and black-box transmission mechanism of the first HTTP service module is as follows: When the platform-side media stream multicast gateway pulls CMAF media fragments, the first HTTP service module reads the CMAF media fragments from the media fragment publishing cache, and simultaneously reads the fragment's IDR frame start timestamp (PTS) from the fragment-level metadata cache. It then encapsulates this into an HTTP return packet with the CMAF media fragment as the response body, and writes the fragment's start PTS into its HTTP header to implement the out-of-band metadata and black-box transmission mechanism. When transmitting each CMAF media fragment... When the media is fragmented, the PTS of the fragment is carried in the HTTP response header. This allows the platform-side media stream multicast gateway to receive the CMAF media fragment and cut it into CMA / RTP fragments without parsing the media fragment's moof box to obtain its start timestamp (PTS). Instead, the PTS of the CMAF media fragment is obtained from its response header. The CMAF media fragment is then cut into CMA / RTP packet payloads as a binary black box and encapsulated into CMA / RTP packets. The out-of-band PTS is used as one of the triple identifiers of each CMA / RTP packet.

7. The broadcast television live broadcast service system based on streaming media protocol according to claim 3, characterized in that: The CMA / RTP packet encapsulation module is used to treat CMAF media segments as black boxes to implement RTP FU-A binary segmentation. Each CMAF media segment is segmented into multiple RTP packet payloads, which are then encapsulated into RTP packets. The PTS of the segment's IDR frame is read from the PTS buffer. A triple identifier of timestamp, sequence number, and FU-A identifier is injected into the header of the segmented and encapsulated RTP packet to complete the CMA / RTP packet encapsulation. The packet is then written to the CMA / RTP packet output queue buffer. The triple identifier is as follows: the first identifier is the starting PTS of the first IDR frame of each CMAF media segment. All RTP packets of the same CMAF media segment are assigned this PTS to indicate that RTP packets with the same timestamp belong to the same CMAF media segment. The second identifier is the sequence number. Each segment's CMA / RTP packet sequence number increments continuously across segments to determine the order of RTP packets or detect packet loss. The incrementing sequence number across segments also provides the sorting order for the media segments. The third identifier is the FU-A identifier. S=1 and E=0 represent the first packet of a media segment, S=0 and E=0 represent intermediate packets, and S=0 and E=1 represent the last packet of the media segment. This identifies the start and end of the sorting of RTP packets for each segment, ensuring that all RTP packets in the same CMAF media segment have the same timestamp, incrementing sequence number, and the FU-A identifier that determines the start and end of the segment's RTP packets. This allows the receiving end to reconstruct and reassemble the CMAF media segment based on these three identifiers.

8. The broadcast television live broadcast service system based on streaming media protocol according to claim 1, characterized in that: The service side of the platform-side media stream encapsulation gateway provides a 25G high-speed UDP interface to listen to and receive the TS / RTP multicast streams of each program encoding output from the platform side in promiscuous mode, which are aggregated by the aggregation switch and broadcast in flood mode, thereby realizing the encapsulation of TS / RTP to CMAF media segments and the encapsulation output of corresponding list / initialization segments. The user side of the platform-side media stream encapsulation gateway provides a 100G media fragmentation interface and a 10G manifest / initialization fragmentation retrieval interface, which are used by the platform-side media stream multicast gateway to retrieve media fragments, manifests and initialization fragments. Requests and responses follow the principle of HTTP protocol that requests and responses are completed on the same TCP connection, and requests and responses for the same data are completed on the same interface. The service side of the platform-side media stream multicast gateway provides media segment retrieval and manifest / initialization segment retrieval interfaces corresponding to the user-side interface of the platform-side media stream encapsulation gateway. It retrieves media segments, manifest files, and initialization segments, and completes CMAF media segment to CMA / RTP multicast encapsulation and manifest / initialization segment proxy. For each program's media segments and manifest files, it retrieves them every 2 seconds to ensure that the manifest and media segment versions are consistent. It also retrieves them once when the initialization segment device starts up or when the version is updated. The user side of the platform-side media stream multicast gateway provides a 25G rate UDP interface and a 10G list / initial fragment HTTP pull interface for flooding mode broadcasting CMA / RTP multicast streams, so that the access network-side streaming media reassembly gateway can receive CMA / RTP multicast streams, list files and initial fragments. The service side of the access network central office streaming media reassembly gateway provides a 25G multicast stream interface and a 10G HTTP interface corresponding to the user-side interface of the platform-side media stream multicast gateway. It listens for and receives CMA / RTP multicast streams in promiscuous mode, pulls the list and initializes fragments through the HTTP interface, parses the CMA / RTP multicast stream and reassembles each CMAF fragment. The user side of the access network central office streaming media reassembly gateway provides a 100G rate HTTP service interface for access network users to pull the manifest file, initialize fragmentation and media fragmentation; The generation time of a media segment is one GOP duration, that is, a media segment is generated every 2 seconds. Therefore, the time interval between fetching and multicasting a media segment is also 2 seconds. The cache management and segment fetching in each link must follow the media segment generation time and GOP duration to enable the segment to be broadcast or fetched as soon as it is generated, so as to ensure the pipeline production and supply of live streaming services from the platform side to the access network bureau side.

9. The broadcast television live broadcast service system based on streaming media protocol according to claim 1, characterized in that: The platform encapsulates the live streaming service into media segment files and converts them into CMA / RTP multicast streams. It uses relay mode to transmit the CMA / RTP multicast streams of CMAF media segment files and uses the HTTP channel to transmit the media segment list and initialization segments. This decouples the low-frequency changing list and initialization segments from the high-frequency changing media segments. The media segments are transmitted through the multicast channel, and the list and initialization segments are transmitted through the HTTP channel, in order to maintain the standard of reliable transmission of streaming media protocol and provide the terminal with standard streaming media protocol broadcast television live streaming service. The access network central office restores and reassembles the CMA / RTP multicast stream into CMAF media fragment files, enabling broadcast television live services, broadband services, and communication services to be transmitted to the user terminal together via the TCP protocol, supporting reception and playback on various smart terminals.

10. A method for transmitting live broadcast television services based on a streaming media protocol according to any one of claims 1 to 9, characterized in that, include: Receive TS / RTP multicast streams from existing live broadcast service platforms; The TS / RTP multicast stream is encapsulated into a CMAF media stream that is encrypted according to the CENC standard and managed by the DRM system key, along with the corresponding manifest file and initialization fragments; The CMAF media stream is converted into a CMA / RTP multicast stream, and the CMA / RTP multicast stream, along with the manifest file and initial fragmentation, is transmitted to the access network office via the core network relay transmission system and the HTTP channel. The access network central office receives the CMA / RTP multicast stream, reassembles and encapsulates the CMA / RTP multicast stream into original CMAF media fragments, and rewrites the URL of the manifest file to achieve synchronization between the manifest file and the reassembled CMAF media fragments. The reorganized CMAF media fragments, manifest files, and initial fragments are accessed through the integrated services access network, along with broadband and communication services, to the CPN network with the user's home router as the gateway, so as to realize the converged access of broadband, communication, and broadcast television services through a single network.

Images