A streaming media transmission method and system

Abstract

The present application relates to a streaming transmission method and system. The method comprises: receiving a request initiated by a client for a default slice resource, the request being for starting streaming playback or for positioning playback; in response to the request, returning a corresponding media slice data stream according to parameters carried by the request or a current state of the service; while returning the media slice data stream, carrying identification information of a next media slice in an HTTP response header; wherein in a live streaming scenario, the request carries a parameter for indicating a delay requirement of the client, and a media slice is selected from generated media slices according to the delay requirement parameter to respond; wherein in a on-demand service scenario, the request carries a time offset parameter for indicating a target playback position, an index file is pre-stored on the server, the index file is queried, a corresponding target media slice is located according to the time offset parameter, and the target media slice is returned. The present application has the advantages of simplicity, fast first screen, accurate dragging, and no need for additional downloading.

Description

TECHNICAL FIELD

[0001] The present application relates to a streaming media transmission method and system, belonging to the technical field of streaming media. BACKGROUND

[0002] With the rapid development of network technology and mobile Internet, streaming media transmission has become the core technical support for multimedia services such as video on demand and online live broadcast. As the key to determining transmission efficiency, playback quality and user experience, the selection and design of streaming media protocol is crucial.

[0003] However, the current mainstream series of streaming media protocols all have their own limitations in actual application. For example, although MPEG-TS protocol has short first screen time and good compatibility in live broadcast scenarios, its fragmentation mechanism lacks flexibility and is difficult to adapt to diversified business needs. HLS protocol uses fragmentation strategy and has good business adaptation ability, but it needs to obtain m3u8 index file additionally, which not only increases bandwidth overhead, but also causes first screen time to be prolonged, media data loading and timeliness to be decreased, and then causes playback stuttering and overall delay to be increased. MP4 protocol structure is relatively complex, and the first screen loading speed is slow, which is not flexible enough in use. Although FMP4 has certain advantages in technology, its compatibility is poor, and many old terminal devices cannot support it. SUMMARY

[0004] The present application provides a streaming media transmission method and system, aiming to at least solve one of the technical problems existing in the prior art.

[0005] The technical solution of the present application relates to a streaming media transmission method, according to the method of the present application, comprising the following steps:

[0006] Receiving a request initiated by a client for a default slice resource, the request is used to start streaming media playback or to position the playback;

[0007] In response to the request, according to the parameters carried by the request or the current state of the service, a corresponding media slice data stream is determined and returned;

[0008] At the same time of returning the media slice data stream, the identification information of the next media slice is carried in the HTTP response header;

[0009] Among them, in the live broadcast scenario, the request carries a parameter for indicating the client's delay requirement, according to the delay requirement parameter, a media slice is selected from the generated media slices for response;

[0010] Among them, in the on-demand service scenario, the request carries a time offset parameter for indicating the target playback position, the server pre-stores an index file, queries the index file, and locates to the corresponding target media slice according to the time offset parameter and returns.

[0011] Further, in the live scene, the method comprises the steps of:

[0012] A100, collecting real-time audio and video data through a collection end, encoding and compressing original audio and video signals to generate code stream data, and encapsulating the encoded code stream data in MPEG-TS transmission stream format and then outputting;

[0013] A200, receiving the MPEG-TS format code stream data from the collection end through a service end, cutting continuous code streams to generate independent TS slice files according to a preset slice generation strategy, and providing a TS slice file download service through the service end;

[0014] A300, downloading and receiving the TS slice files through a client end, and decoding and playing.

[0015] Further, in the step A200, the service end slice process comprises the steps of:

[0016] A211, receiving the encoded stream media data, analyzing the audio and video data packets therein, and identifying and extracting GOPs in a video sequence;

[0017] A212, after completing the analysis of a complete GOP, judging whether a slice should be generated according to a preset slice generation condition;

[0018] If the judgment result is that a slice needs to be generated, the GOP and the corresponding audio data are encapsulated into a standard MPEG-TS format slice file; if the judgment result is that a slice does not need to be generated, the subsequent stream media data packets are continuously analyzed until the next GOP analysis is completed, and the judgment process of step A212 is repeated.

[0019] Further, in the step A200, the service end processing to provide the TS slice file download service process comprises the following steps:

[0020] A221, when the service end receives a request of a client end for a default slice, determining a target TS slice according to the delay requirement of the client end, returning the data of the target TS slice to the client end, and carrying the identification information of the next TS slice in the response header;

[0021] A222, if it is determined that the current target TS slice is the latest generated slice, adding a set identification in the identification information of the next TS slice to indicate that the next slice has not been generated;

[0022] A223. If a request is received from a client for a TS slice with the set identifier, the original TS slice corresponding to the set identifier is located, and an attempt is made to return to the next adjacent TS slice of the original TS slice.

[0023] A224. If the next slice has not yet been generated, the server will return an HTTP 404 status code, and will also include the latest TS slice identifier information in the response header, in order to wait for the client to re-initiate the request.

[0024] Furthermore, in step A300, the process of the client downloading and receiving the TS slice file includes the following steps:

[0025] A310. When the client initiates a download for the first time, it uniformly requests the default slice and carries the delay parameter. The server will return the corresponding TS slice according to the parameter.

[0026] A320. After receiving the response, the client obtains the name of the next slice to be downloaded from the response header and continues to initiate subsequent slice requests based on this name.

[0027] A330. If the identifier information of the next TS segment is contained in the identifier, then wait for a preset time before initiating a download request for the TS segment corresponding to that identifier information.

[0028] A340. If an error response is received for a download request of a TS slice with the aforementioned identifier, the latest TS slice identifier information of the server is obtained from the HTTP header of the error response; it is determined whether the latest TS slice identifier information corresponds to a TS slice that has been downloaded locally; if yes, the download is retried after a preset time; if no, the initial download operation of step A310 is re-executed.

[0029] A350. Continuously repeat steps A310 to A340 to achieve continuous playback.

[0030] Furthermore, in a video-on-demand scenario, the method includes the following steps:

[0031] B100. Process the encoded TS media asset file through the injection end, parse its content to generate a corresponding index file. The index file records the correspondence between the slice name, the byte offset of the slice in the TS media asset file, and the time offset of the slice relative to the media start point. Upload the TS media asset file and the index file.

[0032] B200, Store the TS media asset files and their index files from the injection end through the source station;

[0033] B300: Receives TS slice download requests initiated by clients through the server, queries the index file to locate the byte range of the requested slice, and reads the corresponding data segment from the TS media asset file of the source site as an independent TS slice and returns it.

[0034] B400 initiates a TS slice download request to the server through the client, and receives, decodes and plays the acquired slice data.

[0035] Furthermore, in step B100, the process of generating and uploading the index file at the injection end includes the following steps:

[0036] B110. Parse streaming media data packets. After parsing a complete GOP, determine whether to generate a slice for the current GOP based on the preset slice generation conditions.

[0037] B120. If it is determined that a slice needs to be generated, the index information is updated, and the slice identifier of the current TS slice, the byte offset information in the media asset file, and the time offset information relative to the start point of the media asset are recorded; if it is determined that a slice does not need to be generated, the subsequent streaming media data packets are parsed.

[0038] B130. Repeat steps B110 to B120 until the media asset file is parsed and the updated index information is persisted as an index file.

[0039] B140. Upload the media asset file and the index file together to the source site for storage.

[0040] Furthermore, in step B300, the process of the server providing TS download service includes the following steps:

[0041] B310. When the client sends its first request to the server for the default slice resource, the request carries a time offset parameter.

[0042] B320. If the server receives the first request, it queries the local index file and locates the corresponding target TS slice according to the time offset parameter.

[0043] B330. The server returns the data of the target TS slice to the client, and carries the identification information of the next TS slice and the total duration information of the media asset file in the HTTP response header;

[0044] B340. After the client receives the response, it parses the identification information of the next TS slice from the HTTP response header and initiates continuous download requests for subsequent TS slices in sequence based on the identification information.

[0045] B350. When playback positioning is required, the client re-initiates a request for the default slice resource to the server and updates the time offset parameter to the time offset of the drag target position.

[0046] B360. The server responds to the drag request, returns the located TS slice, and carries the identification information of the next TS slice in the HTTP response header, so that the client can continue to download subsequent TS slices accordingly.

[0047] B370. If the client finds that the identifier of the next TS slice carried in the HTTP response header is the same as the slice identifier of the previous request, it determines that it is the last slice and stops downloading.

[0048] Furthermore, in step B400, the process of the client requesting a TS slice includes the following steps:

[0049] B410. When the client downloads for the first time, it sends a request to the server for the default slice resource and carries a time offset parameter in the request. The time offset parameter is used to specify the time offset from the beginning of the media asset timeline.

[0050] B420. Receive the server's response to the first request, and parse the identification information of the next TS slice from a specific field in the HTTP header of the response to the first request.

[0051] B430. Based on the identifier information of the next TS slice, sequentially initiate continuous download requests for subsequent TS slices;

[0052] B440. When a playback positioning operation is required, a new request for the default slice resource is sent to the server, and the time offset parameter is updated to the time offset of the target time point.

[0053] B450. Receive the server's response to the location request, parse the identification information of the next TS slice from a specific field in the HTTP header of the response, and continue downloading subsequent TS slices based on the identification information;

[0054] B460. During the download process, the identifier information of the next TS segment parsed from the HTTP header is compared with the identifier information of the TS segment requested in the previous request.

[0055] B470. When the comparison results are the same, it is determined that the end of the media asset file has been reached, and the download process is stopped.

[0056] The present invention also relates to a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the above-described method.

[0057] The present invention also relates to a streaming media transmission system, the system including a computer device that includes the aforementioned computer-readable storage medium.

[0058] The technical solution of the present invention also relates to a streaming media transmission system, wherein in a live broadcast scenario, the system is configured with a acquisition end, a server, and a client, the server being communicatively connected to the acquisition end, and the client being configured to initiate a request to the server; wherein in a video-on-demand scenario, the system is configured with an injection end, a source station, a server, and a client, and the server being communicatively connected to the source station.

[0059] The beneficial effects of this invention are as follows:

[0060] This invention discloses a streaming media transmission method and system, which boasts advantages such as simplicity, fast initial display, precise dragging, and no need for additional file downloads, providing users with a better playback experience. This invention requests a unified default slice resource with parameters, and the server directly returns the media slice and provides subsequent navigation information in the response header. Compared to existing technologies that require the client to download and parse an independent index file, resulting in initial display delays, inaccurate dragging, and protocol complexity, this invention uses embedded media navigation information in the HTTP response header, replacing the download of an independent index file. This effectively simplifies the protocol interaction model. Furthermore, it directly maps the initial request to a valid media slice response, skipping the fixed delay of index file acquisition and parsing, effectively shortening the initial display time. Finally, by using an index maintained by the server containing precise time offsets to respond to the client's dragging parameters, the server achieves one-time precise positioning and response, enabling accurate dragging. Attached Figure Description

[0061] Figure 1 This is a basic flowchart of a streaming media method according to an embodiment of the present invention;

[0062] Figure 2 This is a diagram of the live streaming system architecture according to an embodiment of the present invention;

[0063] Figure 3 This is a flowchart of the live stream slice generation process according to an embodiment of the present invention;

[0064] Figure 4 This is a flowchart of the live streaming server processing download requests according to an embodiment of the present invention;

[0065] Figure 5 This is a flowchart of the live streaming client download process according to an embodiment of the present invention;

[0066] Figure 6 This is a diagram of the on-demand system architecture according to an embodiment of the present invention;

[0067] Figure 7 This is a flowchart of the process for generating an index file at the on-demand injection end according to an embodiment of the present invention;

[0068] Figure 8 This is a flowchart of the on-demand server processing download requests according to an embodiment of the present invention;

[0069] Figure 9 This is a flowchart of the on-demand client download process according to an embodiment of the present invention. Detailed Implementation

[0070] The following will provide a clear and complete description of the concept, specific structure, and technical effects of the present invention in conjunction with the embodiments and accompanying drawings, so as to fully understand the purpose, solution, and effects of the present invention.

[0071] It should be noted that, unless otherwise specified, when a feature is referred to as "fixed" or "connected" to another feature, it can be directly fixed or connected to the other feature, or indirectly fixed or connected to the other feature. The singular forms "a," "described," and "the" used herein are also intended to include the plural forms, unless the context clearly indicates otherwise. Furthermore, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this specification is for the purpose of describing particular embodiments only and not for limiting the invention. The term "and / or" as used herein includes any combination of one or more of the associated listed items.

[0072] It should be understood that although the terms first, second, third, etc., may be used to describe various elements in this disclosure, these elements should not be limited to these terms. These terms are used only to distinguish elements of the same type from one another. For example, a first element may also be referred to as a second element without departing from the scope of this disclosure, and similarly, a second element may also be referred to as a first element. Any and all instances or exemplary language (“e.g.,” “such as,” etc.) provided herein are intended only to better illustrate embodiments of the invention and, unless otherwise required, do not impose a limitation on the scope of the invention.

[0073] See Figures 1 to 9In some embodiments, the streaming media transmission method according to the present invention includes at least the following steps: receiving a request from a client for a default segment resource, the request being used to start streaming media playback or perform playback positioning; responding to the request, determining and returning a corresponding media segment data stream based on the parameters carried in the request or the current state of the service; while returning the media segment data stream, carrying the identification information of the next media segment in the HTTP response header; wherein in a live streaming scenario, the request carries parameters for indicating the client's latency requirements, and a media segment is selected from the generated media segments for response based on the latency requirement parameters; wherein in a video-on-demand service scenario, the request carries a time offset parameter for indicating the target playback position, the server pre-stores an index file, the index file is queried, and the corresponding target media segment is located and returned based on the time offset parameter.

[0074] This invention provides a more comprehensive streaming media protocol, offering advantages such as simplicity, fast initial display, precise dragging, and no need for additional file downloads, resulting in a better playback experience for users. This invention requests a unified default slice resource with parameters, and the server directly returns the media slice and provides subsequent navigation information in the response header. Compared to existing technologies that require the client to download and parse a separate index file, leading to initial display delays, inaccurate dragging, and protocol complexity, this invention uses embedded media navigation information in the HTTP response header, replacing the separate index file download. This effectively simplifies the protocol interaction model. Furthermore, it directly maps the initial request to a valid media slice response, skipping the fixed delay of index file acquisition and parsing, effectively shortening the initial display time. Finally, by using an index maintained by the server with precise time offsets to respond to the client's dragging parameters, the server achieves one-time precise positioning and response, enabling accurate dragging.

[0075] In some embodiments, see Figure 2 In a live streaming scenario, the streaming media system of this invention includes a capture end, a server end, and a client end. The capture end is used to capture real-time audio and video data, encode and compress the original audio and video signals to generate stream data, and encapsulate the encoded stream data in MPEG-TS format (Moving Picture Experts Group Transport Stream, an audio and video data container format for real-time transmission) before outputting it. The server end communicates with the capture end and receives the MPEG-TS format stream data from the capture end. According to a preset segmentation strategy, it segments the continuous stream and generates independent TS segment files, while also providing a network download service for these TS segment files. The client end initiates requests to the server to download and receive the TS segment files, and then decodes and plays them, thereby completing the end-to-end transmission of live media data.

[0076] In some specific embodiments of the present invention, see Figure 3 In a live streaming scenario, the server-side slicing process of this invention includes the following steps: First, receiving encoded streaming media data, parsing the audio and video data packets, identifying and extracting Group of Pictures (GOPs) from the video sequence, where a GOP refers to a group of consecutive frames starting from a keyframe (I-frame) and ending before the next keyframe; after completing the parsing of a complete GOP, determining whether a slice should be generated based on preset slice generation conditions; if the determination result is that a slice needs to be generated, then the GOP and its corresponding audio data are encapsulated into a standard MPEG-TS format slice file; if the determination result is that a slice does not need to be generated, then continuing to parse subsequent streaming media data packets until the next GOP is parsed, and repeating the above determination process. Further, the slice generation determination condition can be set to slice duration or the number of GOPs. For example, if the determination condition is set to slice playback duration (e.g., 5 seconds), then a new slice can be generated when the accumulated GOPs reach this playback duration; or, for example, if the determination condition is set to the number of GOPs (e.g., 5), then a new slice can be generated when the accumulated number of GOPs reaches this number.

[0077] In some specific embodiments of the present invention, see Figure 4In a live streaming scenario, the method of this invention provides TS segment download services according to protocol characteristics. The server's process for handling client download requests includes the following steps: When the server receives a client's request for the default segment (media_default.ts, representing the client's initial request or a predefined segment file used as a fallback), it determines the actual TS segment to be returned based on the client's network latency or playback progress, and specifies the name of the next segment in the HTTP response header using a custom field X-Next-Segment, for example, X-Next-Segment: media_1315276.ts; if the currently returned segment is the latest generated segment, the next segment name is appended with the "_next" suffix in the response header as an identifier, for example, X-Next-Segment: The name `media_1315276_next.ts` indicates that the next slice has not yet been generated. When the server receives a request from a client for a slice with the identifier "_next" (such as `media_1315276_next.ts`), the server will first parse the name to locate its corresponding base slice without "_next" (i.e., `media_1315276.ts`), and then attempt to return the next slice generated after that base slice (`media_1315277.ts`). If the next slice has not yet been generated, the server will return an HTTP 404 status code, and at the same time carry the name of the latest available slice in the response header through the `X-Last-Segment` field, for example, `X-Last-Segment:media_1315276.ts`, to instruct the client to re-initiate the request at an appropriate time.

[0078] In some specific embodiments of the present invention, see Figure 5 In a live streaming scenario, the method of this invention involves a client (usually middleware) downloading TS segments according to protocol rules. The process of the client requesting a streaming media segment includes the following steps: When the client initiates a download for the first time, it uniformly requests the default segment and carries a delay parameter in the URL (e.g., media_default.ts?delay=20, where delay represents the client's expected playback delay control amount with the server, in seconds, used by the server to locate the segment based on the actual situation). The server will return the corresponding TS segment based on this parameter. After receiving the response, the client obtains the name of the next segment to be downloaded from the X-Next-Segment field in the response header and continues to initiate subsequent segment requests based on this name.

[0079] If the obtained next slice name contains identifiers such as "_next" (e.g., media_1315276_next.ts, indicating that the slice has not yet been generated on the server), the client will delay for a preset time interval before initiating a download request for that slice.

[0080] If an HTTP 404 error response is received for a slice request with the "_next" identifier, the client obtains the name of the latest available slice on the server from the X-Last-Segment field in the response header and performs the following checks: If the client has already downloaded the slice corresponding to that name, it waits for the same or another preset time before re-initiating the request; if the slice has not yet been downloaded, it means that the client's current progress has fallen behind the server's slice update rhythm. In this case, the client will re-execute the initial download process, that is, re-request the default slice with the delay parameter to resynchronize.

[0081] This section illustrates the live streaming download process of the present invention using a specific embodiment. See also... Figures 2 to 5In a live streaming scenario, the media slice request and response process between the client and server includes the following steps: First, when the client initiates its first request, it retrieves the default slice with the URL / live / media / media_default.ts?delay=5 from the server. The delay parameter specifies the expected live streaming delay; a value of 5 indicates that the client wants to retrieve media content from 5 seconds prior to the current time. Second, the server parses the delay parameter, locates the slice corresponding to 5 seconds prior based on the slice generation sequence recorded internally (assuming it's media_1315276.ts), returns it as the response body, and sets X-Next-Segment: media_1315277.ts in the HTTP response header to indicate the name of the next slice the client should request. Third, the client continues to request the slice / live / media / media_1315277.ts according to the indication in the response header. Fourth, the server finds the corresponding file based on the slice name and returns its data; if the slice is already the most recently generated slice, X-Next-Segment: is set in the response header. The first request is for `media_1315277_next.ts`, which is the original name of the segment with the suffix "_next" appended to it as an identifier that the latest position has been reached. The second request is for ` / live / media / media_1315277_next.ts`. The third request is for `media_1315277_next.ts`. The fourth request is for `media_1315278.ts`. The fifth request is for `media_1315277_next.ts`. The sixth request is for `media_1315277_next.ts`. The seventh request is for `media_1315277_next.ts`. The eighth request is for `media_1315278.ts`. The ninth request is for `media_1315278.ts`. The tenth request is for `media_1315277_next.ts`. The tenth request is for `media_1315277_next.ts`. The tenth request is for `media_1315277_next.ts`. The tenth request is for `media_1315278 ... The client receives a 404 status code and specifies the latest slice name in the response header using the X-Last-Segment field (e.g., X-Last-Segment: media_1315277.ts). Seventh, after receiving the 404 response, the client checks the latest slice name indicated by the X-Last-Segment field in the response header: if the slice has been downloaded, the client waits for a set interval and then re-initiates the request in step (5); if the slice has not been downloaded, it indicates that its progress has fallen behind the server's content update rhythm, so the client returns to the initial request process in step (1) to resynchronize. Eighth, the client achieves continuous downloading and playback of live media content by repeating the above steps.

[0082] Understandably, this invention, in live streaming scenarios, transmits segment information through default segment requests and response headers, demonstrating simplicity, fast initial display, and the elimination of the need for additional file downloads. Specifically, the server in this invention directly carries the next TS segment name through the HTTP response header. The client does not need to parse complex protocols or maintain status; it only needs to download segments sequentially according to the response header. Furthermore, the client's initial request uniformly uses the default segment (media_default.ts) and carries simple parameters (such as delay), simplifying the initial connection process. Compared to the existing HLS / DASH protocol, which forces the client to first download a separate index file and requires the client to implement a set of logic to request, parse, and maintain this index file, this invention eliminates the separate index file download step. All necessary navigation information (such as the next segment name and total media asset duration) is transmitted through HTTP response headers (such as X-Next-Segment). Thus, the client does not need to initiate additional index file requests or parse the index file format; it only needs to process standard HTTP responses, simplifying the client's logic and reducing network round trips. Furthermore, the client initially requests a unified entry point, media_default.ts. The server, based on a strategy (such as the delay parameter), directly returns a valid TS media slice and informs the next slice in the response header. This allows the client to obtain playable media data immediately after the first request and response, skipping the "download-parse index file" step. Compared to existing methods that have a fixed and unavoidable delay before playback begins, this invention avoids the client downloading from the earliest slice and allows direct access to the live stream, effectively shortening the first screen time.

[0083] In some embodiments, in a video-on-demand scenario, see [link to video-on-demand service]. Figure 6 The streaming media system of this invention comprises an injection terminal, a source station, a server, and a client. The injection terminal processes the encoded TS media asset file, generating a corresponding index file by parsing its content. This index file records the correspondence between the slice name, the byte offset of the slice within the TS media asset file, and the time offset of the slice relative to the media start point. Subsequently, the injection terminal uploads and stores the original TS media asset file and the generated index file together to the source station. The source station, acting as a persistent storage node, is responsible for storing the TS media asset file and its index file. The server communicates with the source station and receives TS slice download requests initiated by the client. It locates the byte range of the requested slice by querying the index file and reads the corresponding data segment from the source station's TS media asset file to return as an independent TS slice to the client. The client initiates TS slice download requests to the server and receives, decodes, and plays the acquired slice data, thereby enabling on-demand playback.

[0084] In some specific embodiments of the present invention, see Figure 7 In a video-on-demand scenario, the method of this invention involves the following steps for the injection end to generate an index file: First, the injection end reads the TS media asset file, parses the streaming media data packets within it, and identifies and extracts Groups of Pictures (GOPs) from the video sequence. After parsing a complete GOP, it determines whether the GOP boundary needs to be used as a slice segmentation point based on preset slice generation conditions. If it is determined that a slice needs to be generated, a new record is added to the memory index structure. This record contains the following three pieces of information: the corresponding TS slice file name, the starting byte offset of the slice in the TS media asset file (i.e., the starting point of the byte position of the slice data in the media asset file), and the media asset duration offset of the slice relative to the starting point of the media asset (in time units, representing the position of the slice content on the complete media timeline). If it is determined that a slice does not need to be generated, the subsequent streaming media data packets are parsed until the next GOP is processed. When the entire TS media asset file is completely parsed, the complete index structure established in memory is persistently stored as an index file. Finally, the index file and the TS media asset file are uploaded together to the source server for storage. Furthermore, the criteria for generating a slice can be set to the slice duration or the number of GOPs. For example, if the criteria is set to the slice playback duration (e.g., 5 seconds), a new slice can be generated when the accumulated GOPs reach this playback duration. Or, if the criteria is set to the number of GOPs (e.g., 5), a new slice can be generated when the accumulated number of GOPs reaches this threshold.

[0085] In some specific embodiments of the present invention, see Figure 8In a video-on-demand scenario, the process of the server handling TS segment download requests includes the following steps: When the server receives a default segment request initiated by the client, it first reads the locally stored index file, which records the mapping relationship between each TS segment and the media asset timeline; the server parses the time offset parameter carried in the request (this parameter indicates that the client expects to start playing from a certain point in time of the media asset), and queries the index file based on this parameter to locate the TS segment at the corresponding time point; subsequently, the server returns the name of the next available segment in the HTTP response header through the custom field X-Next-Segment (e.g., X-Next-Segment: media_5.ts, indicating the segment identifier to be requested after the current segment has finished playing), and returns the total duration of the media asset through the field X-Media-Duration (e.g., X-Media-Duration: 7129, in seconds, used for client progress bar display and playback control). If the server receives a request for a specific segment (e.g., media_5.ts), it directly reads the segment data from storage and returns it as the response body, also including the name of the next segment in the response header (e.g., X-Next-Segment: media_10.ts). If the requested segment is determined by the index file to be the last segment, the server still returns the name of this segment in the response header with the X-Next-Segment field, using this as an indicator of the end of playback.

[0086] In some specific embodiments of the present invention, see Figure 9 In a video-on-demand scenario, the method of this invention involves the following steps in which the client requests a TS segment: When the client initiates a download for the first time, it requests a default segment from the server and includes an offset parameter in the URL (e.g., media_default.ts?offset=0, where offset indicates that the client expects to start playback from the beginning of the media asset's timeline, and its value represents the start time offset in seconds). After the server responds, the client obtains the name of the next TS segment from the X-Next-Segment field in the response header, and then downloads subsequent segments sequentially based on that name. When the user performs a drag operation, the client re-requests the default segment and sets the offset parameter to the target time point (e.g., media_default.ts?offset=1280, indicating that it wants to start playback from the 1280th second of the media asset). Upon receiving a response, the client again obtains the name of the next segment from the response header and continues the download sequence. During the download process, if the client finds that the currently obtained name of the next TS segment is the same as the name of the segment requested in the previous request, it determines that the end of the media asset has been reached and stops the download process.

[0087] This section illustrates the on-demand download process of the present invention using a specific embodiment. See also... Figure 1 In a video-on-demand scenario, the process of media segment request and response between the client and server includes the following steps: First, when the client initiates its first request, it retrieves the default segment with the URL / vod / media / media_default.ts?offset=0 from the server. The offset parameter indicates that the client expects to start playback from the beginning of the media asset, and a value of 0 represents a time offset of 0 seconds. Second, the server parses the offset parameter, locates the TS segment (let's say media_0.ts) corresponding to the offset of 0 seconds by querying the locally stored index file, returns it as the response body, and sets X-Next-Segment: media_5.ts in the HTTP response header to indicate the name of the next segment the client should request. Third, the client continues to request the segment / vod / media / media_5.ts according to the indication in the response header. Fourth, after receiving this specific segment request, the server queries and returns the segment data for media_5.ts, and simultaneously sets the next segment name X-Next-Segment: in the response header. Fifth, when the user drags the media asset to a certain time point (e.g., second 1280), the client re-requests the default segment and sets the corresponding offset parameter, i.e., / vod / media / media_default.ts?offset=1280; Sixth, the server queries the index file based on offset=1280, locates the segment at the corresponding time point (let's say media_1280.ts), returns the segment data, and sets X-Next-Segment: media_1285.ts in the response header; Seventh, the client continues to request subsequent segments based on the next segment name in the response header. By repeating the above steps, continuous downloading and playback of on-demand media is achieved.

[0088] Understandably, this invention achieves simplicity, fast initial playback, precise dragging, and no need for additional file downloads in video-on-demand scenarios through an index file (server-side) and an offset parameter. The built-in processing of the index file ensures a lightweight client. Specifically, the client can start playback with a simple HTTP request (e.g., media_default.ts?offset=0). The server uses the local index file for location processing, eliminating the need for the client to process the index file. The server includes the next slice name and total media duration in the response header, requiring no additional calculation or download of metadata from the client. Furthermore, when the client first requests media_default.ts?offset=0, the server directly locates and returns the starting slice by querying the local index file, enabling the client to obtain data with a single request. By inlining the index information into the media response header and directly mapping the entry request to the media data, the "fast initial playback" effect is achieved, significantly reducing initial playback latency. Furthermore, the index file maintained by the server in this invention records the "slice time offset." When the client drags (specifying the target time via the offset parameter), the server can use the local index to perform precise, frame-level queries, directly locating the accurate slice containing the target frame and immediately returning that slice. In contrast, when dragging using existing methods, the client needs to load the index file and find the corresponding slice based on the time point. Since the index file typically only records slice-level time information, not frame-level precision, the positioning is coarse. Moreover, the client often needs to download and parse multiple slices near the target slice to accurately render the target image, resulting in buffering and waiting after dragging using existing methods. This invention shifts the computational burden of precise positioning from the client to the server and utilizes more refined index data to effectively achieve precise dragging.

[0089] It should be understood that the method steps in the embodiments of the present invention can be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable storage medium. The method can use standard programming techniques. Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system. However, if necessary, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language. Furthermore, for this purpose, the program can run on a programmed application-specific integrated circuit (ASIC).

[0090] Furthermore, the procedures described herein may be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by the context. The procedures described herein (or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions, and may be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. The computer program comprises a plurality of instructions executable by one or more processors.

[0091] Furthermore, the method can be implemented in any suitable type of computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices, etc. Aspects of the invention can be implemented as machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it is readable by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein. Furthermore, the machine-readable code, or portions thereof, can be transmitted via wired or wireless networks. The invention described herein includes these and other different types of non-transitory computer-readable storage media when such media comprises instructions or programs that implement the steps described above in conjunction with a microprocessor or other data processor. When programmed according to the methods and techniques described in the invention, the invention may also include the computer itself.

[0092] A computer program can be applied to input data to perform the functions described herein, thereby transforming the input data to generate output data stored in non-volatile memory. The output data can also be applied to one or more output devices, such as a display. In a preferred embodiment of the invention, the transformed data represents physical and tangible objects, including specific visual depictions of physical and tangible objects generated on the display.

[0093] The above description is merely a preferred embodiment of the present invention. The present invention is not limited to the above-described embodiments. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention, as long as they achieve the technical effects of the present invention by the same means, should be included within the scope of protection of the present invention. Within the scope of protection of the present invention, the technical solutions and / or implementation methods can have various modifications and variations.

Claims

1. A streaming media transmission method, characterized in that, The method includes the following steps: Receive a request from the client for the default slice resource, the request being used to start streaming media playback or perform playback positioning; In response to the request, a corresponding media slice data stream is determined and returned based on the parameters carried in the request or the current state of the service; While returning the media slice data stream, the HTTP response header includes the identification information of the next media slice; In the live streaming scenario, the request carries parameters to indicate the client's latency requirements, and a media slice is selected from the generated media slices to respond based on the latency requirement parameters. In the video-on-demand service scenario, the request carries a time offset parameter to indicate the target playback position. The server has a pre-stored index file. The server queries the index file, locates the corresponding target media slice based on the time offset parameter, and returns the result.

2. The method according to claim 1, characterized in that, In a live streaming scenario, the method includes the following steps: A100: Collects real-time audio and video data through the acquisition terminal, encodes and compresses the original audio and video signals to generate bitstream data, and encapsulates the encoded bitstream data in MPEG-TS transport stream format before outputting it. A200: Receives MPEG-TS format bitstream data from the acquisition terminal via the server, cuts the continuous bitstream into independent TS segment files according to a preset segment generation strategy, and provides TS segment file download service via the server. The A300 downloads and receives TS segment files via the client, then decodes and plays them.

3. The method according to claim 2, characterized in that, In step A200, the server-side slicing process includes the following steps: A211. Receive encoded streaming media data, parse the audio and video data packets, and identify and extract GOPs from the video sequence; A212. After completing the parsing of a complete GOP, determine whether slices should be generated based on the preset slice generation conditions. If the determination result indicates that a segment needs to be generated, the GOP and its corresponding audio data are encapsulated into a standard MPEG-TS format segment file; if the determination result indicates that a segment does not need to be generated, the subsequent streaming media data packets are parsed until the next GOP is parsed, and the determination process of step A212 is repeated.

4. The method according to claim 2, characterized in that, In step A200, the server-side processing of the TS slice file download service includes the following steps: A221. When the server receives a request from the client for the default slice, it determines the target TS slice based on the client's latency requirements and returns the data of the target TS slice to the client, while carrying the identification information of the next TS slice in the response header. A222. If it is determined that the current target TS slice is the latest generated slice, then add a setting flag to the identification information of the next TS slice to indicate that the next slice has not yet been generated. A223. If a request is received from a client for a TS slice with the set identifier, the original TS slice corresponding to the set identifier is located, and an attempt is made to return to the next adjacent TS slice of the original TS slice. A224. If the next slice has not yet been generated, the server will return an HTTP 404 status code, and will also include the latest TS slice identifier information in the response header, in order to wait for the client to re-initiate the request.

5. The method according to claim 2, characterized in that, In step A300, the process of the client downloading and receiving the TS slice file includes the following steps: A310. When the client initiates a download for the first time, it uniformly requests the default slice and carries the delay parameter. The server will return the corresponding TS slice according to the delay parameter. A320. After receiving the response, the client obtains the name of the next slice to be downloaded from the response header and continues to initiate subsequent slice requests based on this name. A330. If the identifier information of the next TS segment is contained in the parsed identifier information, then wait for a preset time before initiating a download request for the TS segment corresponding to that identifier information. A340. If an error response is received for a download request of a TS slice with the aforementioned identifier, the latest TS slice identifier information of the server is obtained from the HTTP header of the error response; it is determined whether the latest TS slice identifier information corresponds to a TS slice that has been downloaded locally; if so, the download is retried after a preset time; if not, the initial download operation of step A310 is re-executed. A350. Continuously repeat steps A310 to A340 to achieve continuous playback.

6. The method according to claim 1, characterized in that, In a video-on-demand scenario, the method includes the following steps: B100. Process the encoded TS media asset file through the injection end, parse its content to generate a corresponding index file. The index file records the correspondence between the slice name, the byte offset of the slice in the TS media asset file, and the time offset of the slice relative to the media start point. Upload the TS media asset file and the index file. B200, Store the TS media asset files and their index files from the injection end through the source station; B300: Receives TS slice download requests initiated by clients through the server, queries the index file to locate the byte range of the requested slice, and reads the corresponding data segment from the TS media asset file of the source site as an independent TS slice and returns it. B400 initiates a TS slice download request to the server through the client, and receives, decodes and plays the acquired slice data.

7. The method according to claim 6, characterized in that, In step B100, the process of generating and uploading an index file at the injection end includes the following steps: B110. Parse streaming media data packets. After parsing a complete GOP, determine whether to generate a slice for the current GOP based on the preset slice generation conditions. B120. If it is determined that a slice needs to be generated, the index information is updated, and the slice identifier of the current TS slice, the byte offset information in the media asset file, and the time offset information relative to the start point of the media asset are recorded; if it is determined that a slice does not need to be generated, the subsequent streaming media data packets are parsed. B130. Repeat steps B110 to B120 until the media asset file is parsed and the updated index information is persisted as an index file. B140. Upload the media asset file and the index file together to the source site for storage.

8. The method according to claim 6, characterized in that, In step B300, the process of the server providing TS download service includes the following steps: B310. When the client sends its first request to the server for the default slice resource, the first request carries a time offset parameter. B320. If the server receives the first request, it queries the local index file and locates the corresponding target TS slice according to the time offset parameter. B330. The server returns the data of the target TS slice to the client, and carries the identification information of the next TS slice and the total duration information of the media asset file in the HTTP response header; B340. After the client receives the response, it parses the identification information of the next TS slice from the HTTP response header and initiates continuous download requests for subsequent TS slices in sequence based on the identification information. B350. When playback positioning is required, the client re-initiates a request for the default slice resource to the server and updates the time offset parameter to the time offset of the drag target position. B360. The server responds to the drag request, returns the located TS slice, and carries the identification information of the next TS slice in the HTTP response header, so that the client can continue to download subsequent TS slices accordingly. B370. If the client finds that the identifier of the next TS slice carried in the HTTP response header is the same as the slice identifier of the previous request, it determines that it is the last slice and stops downloading.

9. The method according to claim 6, characterized in that, In step B400, the process of the client requesting a TS slice includes the following steps: B410. When the client downloads for the first time, it sends a request to the server for the default slice resource and carries a time offset parameter in the request. The time offset parameter is used to specify the time offset from the beginning of the media asset timeline. B420. Receive the server's response to the first request, and parse the identification information of the next TS slice from a specific field in the HTTP header of the response to the first request; B430. Based on the identifier information of the next TS slice, sequentially initiate continuous download requests for subsequent TS slices; B440. When a playback positioning operation is required, a new request for the default slice resource is sent to the server, and the time offset parameter is updated to the time offset of the target time point. B450. Receive the server's response to the location request, parse the identification information of the next TS slice from a specific field in the HTTP header of the response, and continue downloading subsequent TS slices based on the identification information; B460. During the download process, the identifier information of the next TS segment parsed from the HTTP header is compared with the identifier information of the TS segment requested in the previous request. B470. When the comparison results are the same, it is determined that the end of the media asset file has been reached, and the download process is stopped.

10. A streaming media transmission system, characterized in that, include: A computer device, the computer device including a computer-readable storage medium; The computer-readable storage medium stores program instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 9; In the live streaming scenario, the system is equipped with a data acquisition terminal, a server, and a client. The server is connected to the data acquisition terminal, and the client is configured to send requests to the server. In the on-demand scenario, the system is configured with an injection terminal, a source station, a server, and a client, with the server communicating with the source station.

Images