WO2018072629A1 - Procédé de poussée de fragments multimédia, serveur et client - Google Patents

Procédé de poussée de fragments multimédia, serveur et client Download PDF

Info

Publication number
WO2018072629A1
WO2018072629A1 PCT/CN2017/105714 CN2017105714W WO2018072629A1 WO 2018072629 A1 WO2018072629 A1 WO 2018072629A1 CN 2017105714 W CN2017105714 W CN 2017105714W WO 2018072629 A1 WO2018072629 A1 WO 2018072629A1
Authority
WO
WIPO (PCT)
Prior art keywords
push
slice
client
fragment
pending
Prior art date
Application number
PCT/CN2017/105714
Other languages
English (en)
Chinese (zh)
Inventor
高莹
顾迎节
张尧烨
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2018072629A1 publication Critical patent/WO2018072629A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method, a server, and a client for pushing a media slice.
  • Hypertext Transfer Protocol English: Hypertext Transfer Protocol, HTTP
  • P2P peer-to-peer
  • Play to local disk HTTP progressive download (English: HTTP Progressive Download)
  • HTTP Dynamic Adaptive Streaming over HTTP (DASH) scheme Among them, DASH put forward a series of technical requirements for all aspects involved in the use of HTTP transmission Moving Picture Experts Group (English: Moving Picture Experts Group, MPEG for short).
  • the DASH standard specifies the format of the media description file (English: Media Presentation description, MPD) and segmentation. Any media resource is composed of shards.
  • the shard is the basic unit for the DASH client to request media resources from the DASH server.
  • the MPD mainly describes the information of the media resources, including the download addresses of the fragments of different code rates.
  • the client can select the appropriate code rate according to the network status, such as the download speed and the number of caches.
  • the server sends the fragment to the client through the HTTP protocol according to the client's selection to ensure the user's viewing experience.
  • part6 DASH with Server Push and WebSockets, which is being developed in the DASH standard (ISO-IEC_23009-6), proposes a push mechanism.
  • the client sends an MPD request message to the server, where the request message carries a Push Directive, where the push command includes an identifier of a fragment that the client wants to push the server, such as initializing the fragment.
  • logo the push command includes an identifier of a fragment that the client wants to push the server, such as initializing the fragment.
  • logo logo.
  • Step 2 The server sends a Push Promise and an MPD to the client in response to the client's request.
  • the push commitment indicates to the stream indicated by the StreamID that the server will push the initial fragment.
  • Step 3 After sending the MPD and the push commitment, the server actively pushes the initialization fragment to the client in the flow specified by the push commitment according to the flow identifier.
  • Step 4 The client sends a fragmentation request message to the server, where the message includes an identifier of the request fragment and a push instruction, where the push instruction includes a fragment identifier that the client wants to push the server; the fragment identifier that the client wants the server to push may be The download address of the slice described by the form of a list or a template may also be a number of consecutive slices after the requested slice is specified. For example, the client requests the fragment 1 and includes the identifier of the fragment 2, the identifier 3 of the fragment, the fragment 4, and the identifier of the fragment 5 in the push instruction.
  • Step 5 The server responds to the request of the client, and sequentially sends the push commitment of the slice 2, the push commitment of the slice 3, the push commitment of the slice 4, the push commitment of the slice 5, the slice 1 to the client, and the push commitment includes A stream identifier and a tile identifier for each tile to be pushed to indicate which tile to push in which stream.
  • Step 6 the flow identifier in the commitment is pushed, and the server pushes the fragment to the client in the specified stream.
  • Step 7 The client receives the fragment pushed by the server according to the fragment identifier and the stream identifier in the push commitment, and performs decoding and playing. Repeat steps 4 through 7 until playback is complete or the user stops watching. Through the server's active push, you can speed up media playback, reduce latency, and reduce message interaction.
  • the method shown in FIG. 1 has the disadvantage that if the number of fragments that the client requests the server to push is large, the server needs to send the push commitment frame corresponding to all the fragments to be pushed later, and then the data of the fragment 1 is sent. For example, if the client pushes the request to push the subsequent 50 fragments, the server will first send 50 push commitment frames to notify the client that the next 50 fragments will be pushed by which stream identifiers respectively, and then the fragments will be sent. 1 data, increased playback delay of the client.
  • the embodiment of the invention provides a method for pushing media fragments and related devices, which can reduce the playback delay of the client.
  • an embodiment of the present invention provides a method for pushing a media slice, including:
  • the server receives the fragment request message sent by the client, and the fragment request message includes a request fragment identifier and a push instruction, where the push instruction is used to instruct the client to request the pushed fragment.
  • the server determines the pushable slice and the pending push slice according to the slice pushed by the client request.
  • the server sends, to the client, a push commitment corresponding to each fragment in the pushable fragment, a fragment corresponding to the request fragment identifier, and a pending push indication information, where the pending push indication information is used to indicate that the client waits to receive the push of the pending push slice. committed to.
  • the server groups the fragments that the client requests to push, so as to send the push commitment corresponding to a part of the fragment first, and then sends the push commitment corresponding to the other fragments in the subsequent process, so as to avoid pushing the request by the client.
  • the large number of shards causes the client to delay playback due to receiving too many push commitments before receiving the requested shards, thereby reducing the playback delay of the client.
  • the server determines the pushable slice and the pending push slice according to the slice that the client requests to push, including: the server divides the slice that the client requests to push according to the first pending push parameter into a pushable Fragmentation and pending push shards.
  • the first pending push parameter is carried in the server local configuration or in the fragment request message.
  • the server determines the pushable slice and the pending push slice according to the first pending push parameter.
  • the first pending push parameter can be locally configured by the server, so that the server can determine the pushable fragment by combining the ability of the server to push the slice.
  • the first pending push parameter may also be set by the client, and the server determines the pushable fragment according to the requirements of the client, and can meet the personalized push requirement of different users compared with the manner that the server sets the first pending push parameter.
  • the server divides the fragment that the client requests to push according to the first pending push parameter into a pushable slice and a pending push slice, specifically: the first pending push parameter is a push threshold, and the server determines the client.
  • the first fragment to the Nth fragment in the fragment requested by the terminal are pushable fragments, and the other fragments except the pushable fragments in the fragment requested by the client request are determined as pending push fragments.
  • N is a positive integer determined by the push threshold; or the first pending push parameter is a random indicator, and the server determines, as a random indicator, the cached slice in the slice requested by the client to be pushable slice And determine the slice other than the pushable slice in the slice pushed by the client request as the pending push slice.
  • the server determines the pushable fragment by pushing the threshold or the currently cached fragment of the server, so that the number of push commitments sent by the server is not excessive, so that the playback delay of the client is avoided.
  • the server further includes: the server is determined according to the first to be determined.
  • Push parameters to determine pushable slices in the pending push slice The server sends the push commitment corresponding to the pushable slice in the to-be-scheduled slice to the client according to the second pending push parameter, and the pushable slice in the pending push slice is the pending push slice. Part or all of the pieces.
  • the second pending push parameter is used to instruct the server to send the condition of the push commitment of the pushable slice in the pending push slice to the client, and the second pending push parameter is carried in the server locally or in the slice request message. .
  • the server determines, according to the second pending push parameter, a sending opportunity of the push commitment corresponding to the pushable slice, so as to timely send the push commitment corresponding to the pushable slice in the to-be-seged slice to the client, Improve the delivery efficiency of push commitments.
  • the second pending push parameter may be locally configured by the server, so that the server can determine the push commitment corresponding to the pushable slice when combined with the ability of the server to push the slice.
  • the second pending push parameter may also be set by the client, and the server determines, according to the requirements of the client, when to send the push commitment corresponding to the pushable slice, and can satisfy the different users according to the manner that the server sets the second pending push parameter. Personalized push requirements.
  • the server sends a push commitment corresponding to the pushable slice in the to-be-scheduled slice to the client according to the second pending push parameter, specifically: when the pushed promise is sent and the push is not pushed.
  • the server sends the push commitment corresponding to the pushable slice in the pending push slice to the client; or, when the pending push slice includes the cached one that meets the second preset quantity
  • the server sends a push commitment corresponding to the pushable slice in the pending push shard to the client.
  • the server determines, according to the remaining number of fragments that have been pushed and not pushed, or the number of cached fragments of the server, when to send the push commitment corresponding to the pushable fragments in the pending push slice to the client. Therefore, the push commitment corresponding to the to-be-seged slice can be sent to the client in time to improve the transmission efficiency of the push commitment.
  • the server further includes: the server receiving the client A cancel push request message sent one by one by a slice that has been pushed and not pushed.
  • the server cancels the push of the pushed push promised and unpushed fragments to the client according to the cancel push request message.
  • the server cancels pushing the shards that have not yet sent the push promise to the client.
  • the client stops playing the media resource it only needs to send the cancel push request message one by one for all the fragments that have been sent and not pushed, without sending the cancel push request for the fragment that has not sent the push commitment.
  • the message reduces the number of times the client sends a cancel push request message, thereby reducing the client's overhead.
  • the server further includes: the server receiving the client
  • the cancel push request message sent by the target fragment, the target fragment is any fragment that has sent the push commitment and is not pushed, and the cancel push request message includes canceling the pending push indication information, and the cancel pending push indication information is used to instruct the server to cancel the direction.
  • the client pushes the shard that has not sent the push promise.
  • the server cancels the push of the target shard to the client according to the cancel push request message, and cancels pushing the shard that has not yet sent the push promise to the client.
  • the client may carry the cancellation pending push indication information in the sent cancellation push request message, instructing the server to cancel pushing the fragment that has not sent the push commitment to the client, and the server determines according to the cancel pending push indication information. It is necessary to cancel the shard that pushes the push promise that has not been sent to the client.
  • the embodiment of the present invention can prevent the server from receiving the last one, as compared with the manner in which the server cancels pushing all the fragments that have been sent and not pushed according to the client, and indirectly determines to cancel the pushing of the fragment that has not yet sent the push commitment to the client. Before the cancel push request message of the shard that has been pushed and not pushed, the server has already sent the push commitment corresponding to the push shard to the client, so that the cancel operation is more timely.
  • the server determines the pushable and pending pushes based on the fragments pushed by the client request. After the fragmentation, the method further includes: the server generates a first fragment list, where the identifier of the fragment that has sent the push commitment and is not pushed and the corresponding stream identifier are recorded in the first fragment list. By maintaining the first shard list, the server can clarify which shards that have sent push commitments have not been pushed.
  • the server further includes: the server generates a second slice list, where the second slice list records The identity of the shard that has not yet sent the push promise.
  • the server sends the push commitment corresponding to the pushable slice in the to-be-seged slice to the client, the server deletes the identifier corresponding to the pushable slice in the pending push slice from the second slice list.
  • the canceling the push request message carries the flow identifier
  • the server cancels the fragment that has sent the pushed push commitment and is not pushed to the client according to the cancel push request message, specifically: the server carries the message according to the push request message.
  • the flow identifier deletes the record corresponding to the flow identifier in the first fragment list.
  • the server cancels the shard that has not sent the push commitment to the client, specifically: the server empties or deletes the second shard list.
  • an embodiment of the present invention provides a method for pushing a media slice, including:
  • the client sends a fragmentation request message to the server.
  • the fragmentation request message includes a request fragment identifier and a push instruction, and the push instruction is used to instruct the client to request the pushed fragment.
  • the client receives the push commitment corresponding to each fragment in the pushable fragment sent by the server, the fragment corresponding to the request fragment identifier, and the pending push indication information, where the pending push indication information is used to instruct the client to wait for the receiving client to request the push.
  • the push commitment of the pending push slice other than the pushable slice in the slice.
  • the client after the client requests the server to push the fragment, the client only receives the push commitment corresponding to the pushable fragment, and determines, according to the pending push indication information returned by the server, the push commitment of the subsequent server to send the remaining fragment.
  • the client on the one hand, it can avoid the problem that the client has a large playback delay due to receiving too many push commitments before receiving the requested fragment; on the other hand, the client only needs to wait for the server to continue to send the remaining
  • the push commitment of the fragment can be used, and the resend fragment request message does not need to be sent to the server again, which saves the message overhead.
  • the fragment request message further includes a first pending push parameter, where the first pending push parameter is used to instruct the server to divide the slice that the client requests to push according to the first pending push parameter into a pushable slice. And pending push shards.
  • the client sets the first pending push parameter, and the server determines the pushable slice and the pending push slice according to the first pending push parameter sent by the client, thereby satisfying the personalized push requirement of different users.
  • the first pending push parameter includes a push threshold for indicating the number of pushable slices or a random indicator for instructing the server to determine the cached slice as a pushable slice.
  • the client sets a push threshold or a random indicator, so that the server determines the pushable fragment according to the push threshold or the currently cached fragment of the server, so as to ensure that the number of push commitments sent by the server is not excessive. Therefore, the playback delay of the client is prevented from being large.
  • the client after receiving the push commitment corresponding to each fragment in the pushable fragment sent by the server, the fragment corresponding to the request fragment identifier, and the pending push indication information, the client further includes: the client receiving server
  • the push commitment corresponding to the pushable slice in the sent push slice to be sent, the pushable slice in the pending push slice is a part or all partial slices in the pending push slice.
  • the client can also receive the push commitment corresponding to the pushable fragment in the to-be-seged slice, so as to implement the push commitment in batches, compared to the prior art, in the embodiment of the present invention, the client The terminal does not receive the push commitment corresponding to all the fragments requested by the client at one time, and avoids the large number of fragments pushed by the client request, so that the client receives too many pushes before receiving the requested fragment. Commitment leads to a problem with a large playback delay, which can reduce the playback delay of the client.
  • the fragment request message further includes a second pending push parameter, where the second pending push parameter is used to instruct the server to determine, according to the second pending push parameter, the corresponding pushable slice in the pending push slice.
  • the client sends a second pending push parameter to the server, so that the server determines, according to the second pending push parameter, a sending opportunity of the push commitment corresponding to the pushable slice.
  • the second pending push parameter includes: when the remaining number of fragments that have been sent and not pushed is smaller than the first preset quantity, the server will correspond to the pushable fragments in the pending push slice.
  • the push commitment is sent to the client; or, when the pending push shard includes the cached shard that meets the second preset number, the server sends the push commitment corresponding to the pushable shard in the pending push shard to the client.
  • the client may receive the push commitment corresponding to the pending push fragment in time.
  • the client after the client receives the push commitment corresponding to each of the shards sent by the server, the shard corresponding to the request shard identifier, and the pending push indication information, the client includes: A shard that pushes the promise and is not pushed, sends a cancel push request message to the server one by one, and the cancel push request message is used to instruct the server to cancel the shard that has pushed the pushed push promise to the client and has not been pushed.
  • the client stops playing the media resource it only needs to send the cancel push request message one by one for all the fragments that have sent the push promise and not pushed, without sending the cancel push request for the fragment that has not sent the push promise.
  • the message reduces the number of times the client sends a cancel push request message, thereby reducing the client's overhead.
  • the client after receiving the push commitment corresponding to each fragment in the pushable fragment sent by the server, the fragment corresponding to the request fragment identifier, and the pending push indication information, the client further includes: the client targets the target.
  • the fragment sends a cancel push request message to the server.
  • the target fragment is any fragment that has sent the push commitment and is not pushed.
  • the cancel push request message includes canceling the pending push indication information, and the cancel pending push indication information is used to instruct the server to cancel the direction.
  • the client pushes the shard that has not sent the push promise.
  • the client may carry the cancellation pending push indication information in the sent cancellation push request message, instructing the server to cancel pushing the fragment that has not sent the push commitment to the client, and the server determines according to the cancel pending push indication information. It is necessary to cancel the shard that pushes the push promise that has not been sent to the client.
  • the embodiment of the present invention can prevent the server from receiving the last one, as compared with the manner in which the server cancels pushing all the fragments that have been sent and not pushed according to the client, and indirectly determines to cancel the pushing of the fragment that has not yet sent the push commitment to the client. Before the cancel push request message of the shard that has been pushed and not pushed, the server has already sent the push commitment corresponding to the push shard to the client, so that the cancel operation is more timely.
  • the client after receiving the push commitment corresponding to each fragment in the pushable fragment sent by the server, the fragment corresponding to the request fragment identifier, and the pending push indication information, the client further includes: the client according to the server The sent push promise determines that the shard can be pushed, and the pending push shard is determined based on the pushable shard and the shard that the client requests to push.
  • the client after the client determines the pushable fragment according to the push commitment sent by the server, and determines the pending push fragment according to the pushable fragment and the slice requested by the client, the client also generates: a first fragment list in which the identifier of the fragment that has sent the push commitment and is not pushed and the corresponding stream identifier are recorded.
  • the client can clarify which shards that have sent push commitments have not been pushed.
  • the client determines the pushable fragment according to the push commitment sent by the server, and determines the pending push fragment according to the pushable fragment and the fragment requested by the client request, and further includes: the client generates the first Two-part column In the table, the identifier of the fragment that has not sent the push commitment is recorded in the second fragment list.
  • the method further includes: the client deleting the identifier corresponding to the pushable fragment in the pending push fragment from the second fragment list .
  • the client after the client sends the cancel push request message to the server one by one, the client sends the first slice list and the second slice list to the server. Or delete.
  • an embodiment of the present invention provides a server, which has a function of implementing server behavior in the foregoing first aspect.
  • the functions can be implemented in hardware or in hardware by executing the corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the structure of the server includes a processor and a memory for storing a program that supports the server to perform the above method, and the processor is configured to execute a program stored in the memory.
  • the server can also include a communication interface for the server to communicate with other devices or communication networks.
  • an embodiment of the present invention provides a client, where the client has a function of implementing client behavior in the foregoing second aspect.
  • the functions can be implemented in hardware or in hardware by executing the corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the client structure includes a processor and a memory for storing a program that supports the client to perform the above method, and the processor is configured to execute a program stored in the memory.
  • the client can also include a communication interface for the client to communicate with other devices or communication networks.
  • the present invention provides a server, the server comprising a module or unit for performing the push method of the media slice described in the above first aspect or any one of the first aspects.
  • the present invention provides a client comprising a module or unit for performing a push method of a media slice as described in any of the possible aspects of the second aspect or the second aspect above.
  • the present invention provides a communication system, including a server and a client, wherein the server is the server described in the third aspect or the fifth aspect, and the client is the client described in the fourth aspect or the sixth aspect. .
  • an embodiment of the present invention provides a computer storage medium for storing computer software instructions used by the server, which includes a program designed to execute the first aspect of the server.
  • an embodiment of the present invention provides a computer storage medium for storing computer software instructions used by the client, which includes a program designed to execute the second aspect of the foregoing client.
  • the server divides the fragment requested by the client into a pushable fragment and a pending push fragment, and sends a push commitment and a pending push indication information corresponding to each of the pushable fragments to the client, the client.
  • the new push commitment can be received according to the pending push indication information when subsequently receiving the pushed fragment. Therefore, when the number of fragments requested by the client is large, the client can be prevented from receiving due to the need to receive a large number of push commitments. The problem of large fragmentation delay.
  • FIG. 1 is a schematic flow chart of a method for pushing a media slice in a conventional technology
  • FIG. 2 is a schematic structural diagram of a media slice pushing system according to an embodiment of the present invention.
  • FIG. 3 is a schematic structural diagram of a computer device according to an embodiment of the present invention.
  • FIG. 4 is a schematic flowchart of a method for pushing a media slice according to an embodiment of the present invention
  • FIG. 5 is a schematic flowchart of a method for canceling push media segmentation according to an embodiment of the present invention
  • FIG. 6 is a schematic structural diagram of a server according to an embodiment of the present disclosure.
  • FIG. 7 is a schematic structural diagram of a client according to an embodiment of the present invention.
  • FIG. 2 is a schematic structural diagram of a media sharding push system 200 according to an embodiment of the present invention, including: a server 201, a client 202, and a network 203.
  • Client 202 communicates with server 201 over network 203.
  • the client is responsible for sending a fragmentation request message to the server for requesting the acquisition of the fragment, wherein the fragment includes the initialization fragment and the media fragment.
  • the initialization fragment includes metadata required for media resource playback, and the media fragment includes real data of the media resource.
  • the fragment request message includes a request fragment identifier for requesting data of a certain fragment.
  • the fragmentation request message may further include a push instruction, where the push instruction includes an identifier of a fragment that the client wishes the server to push.
  • the fragment identifier that the client wants to push the server may be a download address describing the fragment in the form of a list or a template, or may be a consecutive fragment after the requested fragment is specified.
  • the slice request message may also include a pending push parameter.
  • the pending push parameter is used to indicate the number of push commitments sent by the server each time or when to send a push commitment for the slice to be pushed.
  • the pending push parameter may specifically be that a maximum of several push commitments are sent at a time, or at least a few push commitments are sent at a time, or a subsequent interval of each batch of push commitments after the first batch of push commitments is sent, or any other It can be used to decide the number of sent push promises or when to send the push promise, such as the number of fragments in the client cache.
  • the client is also used to receive fragments sent or pushed by the server, and is responsible for decoding, decrypting, rendering, and rendering of the fragments.
  • the server is responsible for storing and distributing the fragment, receiving the fragment request message of the client, parsing the push instruction in the fragment request message, and dividing the fragment pushed by the client request into two groups according to the push instruction, and one group is pushable fragment.
  • the other group is pending push shards.
  • the server first sends a push commitment corresponding to each fragment in the pushable fragment to the client, and in the process of subsequently pushing the fragment, the push commitment of the pending push fragment is sent to the client in batches to ensure that each The number of push commitments sent at a time is not excessive, so that the client avoids the problem of large delay caused by receiving too many push commitments when receiving the pushed fragments.
  • the server may further determine the number of transmission commitments and the transmission timing according to the pending push parameters sent by the client, and then send the push commitment to the client according to the number of transmissions and the sending timing.
  • the method in the embodiment of the present invention not only supports the HTTP-based dynamic adaptive stream (DASH) technology, but also applies to other HTTP stream technologies, including HTTP live stream (English: HTTP Live Streaming, referred to as HLS). , HTTP Dynamic Streaming (HDS) and HTTP Smooth Streaming (English: HTTP Smooth Streaming, referred to as HSS).
  • HTTP live stream English: HTTP Live Streaming, referred to as HLS
  • HDS HTTP Dynamic Streaming
  • HTTP Smooth Streaming English: HTTP Smooth Streaming, referred to as HSS
  • the number of the clients 202 may also be multiple, which is not limited by the embodiment of the present invention.
  • the client 202 can be any terminal such as a mobile phone, a tablet computer, a desktop computer, or a notebook computer.
  • the server 201 or the client 202 in FIG. 2 may be the computer device (or system) in FIG. The way to achieve it.
  • FIG. 3 is a schematic diagram of a computer device according to an embodiment of the present invention.
  • Computer device 300 includes at least one processor 301, a communication bus 302, a memory 303, and at least one communication interface 304.
  • the processor 301 can be a general-purpose central processing unit (English: Central Process ing Unit, CPU for short), a microprocessor, an application-specific integrated circuit (ASIC), or one or more An integrated circuit for controlling the execution of the program of the present invention.
  • CPU Central Process ing Unit
  • ASIC application-specific integrated circuit
  • Communication bus 302 can include a path for communicating information between the components described above.
  • the communication interface 304 uses a device such as any transceiver for communicating with other devices or communication networks, such as an Ethernet, a radio access network (English: Radio Access Technology, RAN), and a wireless local area network (English: Wireless Local Area Networks, referred to as WLAN).
  • a radio access network English: Radio Access Technology, RAN
  • WLAN Wireless Local Area Networks
  • the memory 303 may be a read-only memory (English: Read-Only Memory, ROM for short) or other types of static storage devices that can store static information and instructions, a random access memory (English: Random Access Memory, RAM for short). Other types of dynamic storage devices that can store information and instructions, or can be electrically readable Erasable Programmable Read-Only Memory (EEPROM) or read-only discs (English: Compact Disc Read) -Only Memory (CD-ROM) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), disk storage media or other magnetic storage devices, or can be used to carry Or any other medium having a desired program code in the form of an instruction or data structure and accessible by a computer, but is not limited thereto.
  • the memory can exist independently and be connected to the processor via a bus. The memory can also be integrated with the processor.
  • the memory 303 is used to store program code for executing the solution of the present invention, and is controlled by the processor 301 for execution.
  • the processor 301 is configured to execute program code stored in the memory 303.
  • processor 301 may include one or more CPUs, such as CPU0 and CPU1 in FIG.
  • computer device 300 can include multiple processors, such as processor 301 and processor 308 in FIG. Each of these processors can be a single-CPU processor or a multi-core processor.
  • processors herein may refer to one or more devices, circuits, and/or processing cores for processing data, such as computer program instructions.
  • computer device 300 may also include an output device 305 and an input device 306.
  • Output device 305 is in communication with processor 301 and can display information in a variety of ways.
  • the output device 305 can be a liquid crystal display (English: Liquid Crystal Display, abbreviated as: LCD), a light emitting diode (English: Light Emitting Diode, abbreviated as: LED) display device, a cathode ray tube (English: Cathode Ray Tube, referred to as : CRT) Display device, or projector (projector), etc.
  • Input device 306 is in communication with processor 301 and can accept user input in a variety of ways.
  • input device 406 can be a mouse, keyboard, touch screen device, or sensing device, and the like.
  • the computer device 300 described above can be a general purpose computer device or a special purpose computer device.
  • the computer device 300 can be a desktop computer, a portable computer, a network server, a handheld computer (English: Personal Digital Assistant, PDA for short), a mobile phone, a tablet computer, a wireless terminal device, a communication device, an embedded device, or There are devices of similar construction in Figure 3. Embodiments of the invention do not limit the type of computer device 300.
  • the server 201 in FIG. 2 may be the device shown in FIG. 3, and one or more software modules (such as an interaction module and a processing module) are stored in the memory of the server 201.
  • the client 202 in FIG. 2 can also be the device shown in FIG.
  • One or more software modules (such as interaction modules and processing modules) are stored in the memory of the client.
  • the server or the client can implement the software module through the processor and the program code in the memory to implement the push of the slice.
  • FIG. 4 is a flowchart of a method for pushing a media slice according to an embodiment of the present invention, including the following steps.
  • S401 The client sends a fragment request message for obtaining the fragment 1 to the server, where the fragment request message includes a push instruction.
  • the fragment request message carries the identifier of the fragment 1 and a push instruction.
  • the push command is used to determine the identifier that the client expects the server to push the shards.
  • the client wants the server to push the shard 2, the shard 3, the shard 4, and the shard 5 as an example.
  • the identifier of the fragment includes, but is not limited to, a uniform resource locator (English: Uniform Resoure Locator, abbreviated as: URL).
  • the client sends a fragment request message carrying a push instruction to the server as shown in the following code 1:
  • the server receives the fragment request message sent by the client, and divides the fragment that the client requests to push into a pushable fragment and a pending push fragment.
  • the server divides the fragment that the client requests to push into a pushable slice and a pending push slice according to the first pending push parameter.
  • the first pending push parameter may be locally configured by the server.
  • the first pending push parameter may be set according to a specific application scenario, and is used to divide the slice that the client requests to push into a pushable slice and a pending push slice, so that the client may request to send the segment in batches.
  • the push promise of the film avoids sending too many push promises at once. causess the client to play delayed.
  • the first pending push parameters include, but are not limited to, a push threshold (eg, a maximum number of push commitments sent at a time, a minimum number of push commitments sent at a time), a random indicator.
  • the push threshold is used to indicate how many shards the server determines as pushable shards.
  • the random indicator is used to instruct the server to determine the currently locally cached slice as a pushable slice.
  • the server sequentially sorts the 50 fragments of the client request from the first slice according to the quantity 4 (ie, the slice 2
  • the fourth slice ie, slice 5
  • the remaining 46 slices are determined as pending push slices.
  • the server currently caches only the fragment 2 to the fragment 5, and the server determines the fragment 2 to the fragment 5 as pushable fragments, and the remaining 46 The slice is determined to be a push slice to be determined.
  • S403 The server sends the push commitment of the slice 2, the push commitment of the slice 3, the push commitment of the slice 4, the push commitment of the slice 5, the pending push indication information, and the slice 1 to the client in response to the request of the client.
  • the push commitment indicates that the server will push the fragment in the stream indicated by the stream ID.
  • the server sends a push commitment for the slice 2, the slice 3, the slice 4, and the slice 5 respectively.
  • these four push commitments are sent to the client before sending the fragment 1.
  • the push commitment of the slice 2, the push commitment of the slice 3, the push commitment of the slice 4, the push commitment of the slice 5, the pending push indication information, and the slice 1 may be part of the same response message. , carrying the same stream ID.
  • the server sends push commitments and shards 1 to the client as shown in the following code 2-6:
  • the format is a Boolean type. In other implementable manners, the format of the pending push indication information may also be other types.
  • " ⁇ binary data for segment 1 ⁇ " is the data of slice 1 requested by the client.
  • the HEADERS frame in which the server pushes the pending push indication information in the returned response message is taken as an example.
  • the pending push may also be performed.
  • the indication information is carried in a certain push commitment sent by the server, or is carried in a newly defined certain message or a certain frame, which is not specifically limited in the embodiment of the present invention.
  • the server may further maintain a fragment list that has sent the push commitment and is not pushed, and the identifier of the fragment that has sent the push commitment and is not pushed and the corresponding stream identifier are recorded in the list.
  • the server sends a push commitment for each pushable fragment to the client.
  • the server sends a push commitment from slice 2 to slice 5 to the client
  • the pushed push commitment is sent.
  • the URL of the slice 2 to the slice 5 and the corresponding stream identifier are recorded in the un-pushed slice list.
  • the format of the slice list that has sent the push commitment and is not pushed can be as shown in Table 1.
  • Table 1 lists of fragments that have been sent push commitments and have not been pushed
  • the server can also maintain a list of pending push fragments, which record the identity of the fragment that the client requested to push and that the server has not sent the push commitment. For example, after the server divides the fragment requested by the client into the pushable slice and the pending push slice, the URL of the slice 6 to the slice 51 is recorded in the pending push slice list.
  • the format of the pending push slice list can be as shown in Table 2.
  • S404 The client receives the push commitment of the slice 2 sent by the server, the push commitment of the slice 3, the push commitment of the slice 4, the push commitment of the slice 5, the pending push indication information, and the slice 1, processing and playing the score Slice 1.
  • the client first receives the push commitment corresponding to each fragment in the pushable fragment, and according to the push commitment client, the client can know which stream the subsequent server will push, according to the fragment identifier carried in the push commitment. And the corresponding flow identifier, the client can maintain a fragment list that has sent the push commitment and has not been pushed.
  • the list records the identifier of the fragment that the server has sent the push commitment and has not pushed to the client, and the corresponding stream identifier. For example, if the URL of the slice 2 to the slice 5 and the corresponding stream identifier are recorded in the slice list that has been sent and the push is not pushed, the format of the slice list that has sent the push commitment and is not pushed can be seen in Table 1.
  • the client learns, according to the received push indication information, that it needs to wait for the push commitment of the other fragments in the fragment that the client requests to push to send the push commitment. Specifically, the client may further determine, according to the fragment that is pushed by the request and the fragment that the server has sent the push commitment, the fragment that has not sent the push commitment, and maintain a pending push fragment list, where the client request is recorded in the list. The identity of the shard that was pushed and the server has not sent a push commitment. For example, the URL of the slice 6 to the slice 51 is recorded in the pending push slice list. See Table 2 for the format of the pending push slice list.
  • the client receives the data of the slice 1, processes and plays the slice 1, and waits for the slice pushed by the server.
  • S405 The server pushes the fragment 2 to the client.
  • the server is The client sends the fragment 2 as shown in the following code 7:
  • the server pushes the fragment 2 to the client, the identifier of the fragment 2 and the stream identifier 2 are deleted from the sent push promised and unpushed fragment list in the server, thereby updating the list.
  • S406 The client receives the fragment 2 sent by the server, and processes and plays the fragment 2.
  • the client After receiving the fragment 2 sent by the server, the client deletes the identifier of the fragment 2 and the stream identifier 2 from the sent push promised and unpushed fragment list in the client, thereby updating the list.
  • the client may further determine whether the response message includes a push commitment.
  • the server pushes the fragment 3 and the fragment 4 to the client, and the client receives the fragment 3 and the fragment 4 pushed by the server.
  • the server For the process, reference may be made to step S405 and step S406, and details are not described herein again.
  • the server pushes a fragment to the client, it needs to delete the corresponding fragment identifier and the corresponding stream identifier from the server's sent push promised and unpushed fragment list, thereby updating the server's sent push commitment and not pushing.
  • the shard list is a fragment identifier and the corresponding stream identifier from the server's sent push promised and unpushed fragment list, thereby updating the server's sent push commitment and not pushing.
  • the client Each time the client receives a push fragment, the client needs to delete the corresponding fragment identifier and the corresponding stream identifier from the fragment list of the client that has sent the push commitment and does not push, and updates the sent push commitment of the client and does not push.
  • the shard list Each time the client receives a push fragment, the client needs to delete the corresponding fragment identifier and the corresponding stream identifier from the fragment list of the client that has sent the push commitment and does not push, and updates the sent push commitment of the client and does not push.
  • S407 The server determines a pushable slice in the pending push slice.
  • the server determines, according to the first pending push parameter, the pushable slice in the pending push slice.
  • the specific form of the first pending push parameter is described in step 402, and details are not described herein again.
  • the server sends the first of the remaining 46 fragments after sending the push commitment corresponding to the slice 2 to the slice 5
  • the slices (ie, slice 6) to the fourth slice (ie, slice 9) are determined to be pushable slices.
  • the server currently caches only the fragment 6 to the fragment 9, and the server determines the fragment 6 to the fragment 9 as pushable fragments.
  • S408 The server sequentially sends the push commitment of the slice 6, the push commitment of the slice 7, the push commitment of the slice 8, the push commitment of the slice 9, and the slice 5 to the client.
  • the server determines, according to the second pending push parameter, a condition for sending a push commitment of the pushable slice in the pending push slice to the client, and when the condition is met, the server corresponds to the pushable slice in the pending push slice.
  • the push promise is sent to the client.
  • the second pending push parameter may be locally configured by the server.
  • the second pending push parameters include, but are not limited to, a minimum value of the remaining number of fragments that have sent the push commitment and are not pushed, or a threshold number of fragments of the server currently buffered.
  • the push commitment corresponding to the pushable shards included in the pending push shard is sent to the client. That is, when the server determines that the push has been sent When there is only one record left in the slice list that is delivered and not pushed, it is determined that the push commitment corresponding to the pushable slice included in the pending push slice is sent to the client. For example, the pushable slice in the pending push slice is slice 6 to slice 9. When the server determines that only the slice 5 is left in the slice list that has been sent and not pushed, the remaining number is less than 2
  • the server sends the corresponding push commitments of each of the fragments 6 to 9 to the client. Preferably, the server may send a push commitment corresponding to each of the fragments 6 to 9 to the client before sending the fragment 5 to the client.
  • the server locally configures 4 slices per cache
  • the corresponding push commitments of the 4 segments can be sent. For example, when the server pushes the fragment 2 to the fragment 5 to the client, the server caches more fragments, for example, the fragment 6 to the fragment 9 in the pending push fragment list, and the number of cached fragments. If four are satisfied, the server sends the corresponding push commitment of each of the fragments 6 to 9 to the client.
  • the server when the condition indicated by the second pending push parameter is met, the server needs to send a part of the push commitment again, on the one hand, avoiding sending too many push commitments each time, causing the client to play the delay;
  • the push commitment of the subsequent fragments is sent to the client in time to avoid the playback delay caused by the client not receiving the fragment pushed by the server in time.
  • the second pending push parameter is only exemplified herein, and the specific form of the second pending push parameter is not limited by the present invention.
  • the code format of the push commitment of the fragment 6 to the fragment 9 sent by the server to the client may refer to the code format of the push commitment of the fragment 2 to the fragment 5, and details are not described herein again.
  • the server sends the fragment 5 to the client as shown in the following code 8:
  • push-policy “urn:mpeg:dash:fdh:2016:push-template”; “http://example/rendition1/segment ⁇ %03d ⁇ : ⁇ 6-9 ⁇ ” means the server The next push strategy is to push slice 6 to slice 9.
  • the server may also carry the pending push indication information, and notify the client to send the push commitment of the remaining fragments that have not yet sent the push commitment. For example, if the server sends the fragment 1 to the client, indicating that the current push is the fragment 2 to the fragment 5, and carries the pending push indication information, the server sends the fragment 5 to the client, in addition to the need. In addition to the information indicating that the push is from slice 6 to slice 9, the push push indication information may be carried, and the client has been notified to continue to wait for the push commitment of the remaining slice that has not yet sent the push commitment. In this case, the server sends the fragment 5 to the client as shown in the following code 9:
  • the server also needs to delete the identifier of the fragment 6 to the fragment 9 from the pending push fragment list, and simultaneously add the identifier of the fragment 6 to the fragment 9 and the corresponding stream identifier to the score that has been sent and not pushed.
  • the slice list After the server pushes the fragment 5 to the client, the server deletes the identifier of the fragment 5 from the fragment list that has sent the push commitment and has not been pushed, thereby updating the list. It should be noted that when the pending push fragment list in the server is empty, it indicates that the push commitment of the fragment requested by the client has been completely transmitted. At this time, the server will not need to send the pending push indication information to the client. .
  • the order in which the server sends the corresponding push commitments from the fragment 6 to the fragment 9 to the client and the server sends the fragment 5 to the client is not specifically limited.
  • the client receives the push commitment corresponding to the fragment 6 sent by the server, the push commitment corresponding to the fragment 7, the push commitment corresponding to the fragment 8, the push commitment corresponding to the fragment 9, and the fragment 5, and processes and plays the fragment. 5.
  • the client first receives the push commitment corresponding to each of the pushable fragments in the to-be-pushed slice, and according to the push commitment client, the client can know which stream the subsequent server will push, according to the push commitment.
  • the fragment identifier and the stream identifier corresponding to the fragment the client can update the fragment list that has sent the push commitment and has not been pushed. For example, the identifier of the fragment 6 to the fragment 9 and the stream identifier corresponding to the fragment 6 to the fragment 9 are added to the fragment list of the client that has sent the push commitment and is not pushed, and at the same time, the fragment 6 to the fragment is segmented.
  • the identity of 9 is removed from the client's pending push slice list.
  • the client processes and plays the slice 5 and waits for the slice 6 to slice 9 pushed by the receiving server.
  • the client learns, according to the pending push indication information, that it needs to wait for receiving the push commitment of the other fragments that have not sent the push commitment.
  • S410 The server pushes the last fragment that has sent the push commitment and has not been pushed to the client.
  • step S410 steps S407 to S409 are repeated between the server and the client until the condition of step S410 is satisfied.
  • the last slice that has sent the push commitment and has not been pushed should be the slice 51.
  • S411 The client receives the last fragment that has been sent by the server and has not been pushed, and processes and plays the fragment, and the playback ends.
  • steps S401 to S411 in the embodiment of the present invention may be repeated until all the fragmentation ends. Repeated descriptions are not repeated here.
  • the server divides the slice that the client requests to push into two parts: a pushable slice and a pending push slice, and firstly pushes the push commitment corresponding to the pushable slice, the pending push indication information, and the client request.
  • the fragment is sent to the client, and in the process of subsequently pushing the fragment, the push commitment of the pending push fragment is sent to the client in batches to ensure that the number of push commitments sent each time is not excessive, avoiding Because the client requests to push the fragmentation There are many problems that result in a large delay caused by receiving a large number of push commitments before receiving the requested fragment, thus reducing the playback delay of the client.
  • the server can only send push commitments for fragments that can send push commitments, even if a push commitment can be sent.
  • the server Before the shards are all pushed, when there are more shards on the server that can be pushed, this part of the shards will not be actively pushed to the client. The client can only send the fragment request message again after receiving all the pushed fragments to obtain more fragments.
  • the server sends a push commitment to the client according to the currently cached fragment, and the client may determine, according to the pending push indication information sent by the server, to continue to receive the pending push fragment in the subsequent process.
  • Push commitment so there is no need to send the fragment request message again for the fragment that has requested the push, which saves the overhead of the client sending the fragment request message again.
  • the first pending push parameter may also be set by the client, and the client sends the first pending push parameter to the server in the slice request message of the slice 1.
  • the server receives the fragment request message that is sent by the client and carries the first pending push parameter, and divides the fragment that the client requests to push into the pushable slice and the pending push slice according to the first pending push parameter, and the division manner can be referred to The description of the above step S402 will not be repeated here.
  • the client sends a fragment request message carrying the first pending push parameter to the server as shown in the following code 10:
  • the second pending push parameter may also be set by the client, and the client sends the second pending push parameter in the slice request message of the slice 1 and sends it to the server.
  • the server receives a fragmentation request message that is sent by the client and carries a second pending push parameter, and determines, according to the second pending push parameter, when to send the push commitment corresponding to the pushable slice in the to-be-scheduled slice to the client, and determines
  • the client sends the second pending push parameter in the slice request message of the slice 1 and sends it to the server.
  • the server receives a fragmentation request message that is sent by the client and carries a second pending push parameter, and determines, according to the second pending push parameter, when to send the push commitment corresponding to the pushable slice in the to-be-scheduled slice to the client, and determines
  • the client sends a fragment request message carrying the first pending push parameter to the server, as shown in the following code 9, wherein the latestPush is used as the second pending push parameter, that is, the client wants the server to push the last sent push promise. And the unsubmitted shards are sent the next batch of push promises that can push the shards.
  • the server needs to determine the pushable slice jointly by combining the first first pending push parameter and the first pending push parameter sent by the client. If the server is locally configured to send up to 4 push commitments at a time, and the first pending push parameter sent by the client indicates that the minimum number of push commitments sent each time is 5, the server prioritizes its own pushability and will be able to push points. The number of pieces is determined to be four. Similarly, if the server is configured with the second pending push parameter locally, the server needs to determine, together with the local second pending push parameter and the second pending push parameter sent by the client, when to push the sliceable slice in the pending push slice. The push promise is sent to the client.
  • the server may further carry the first pending push parameter and/or the second pending push parameter.
  • the server sends a slice 1 to the client as shown in code 11:
  • the pending push parameter and/or the second pending push parameter that is, the maximum number of push commitment frames per transmission is five, and the next batch of pushable fragments is sent when the last slice that has sent the push commitment and is not pushed is pushed. Push promise.
  • the first pending push parameter and/or the second pending push parameter are set by the client, and can be provided more than the method of setting the first pending push parameter and/or the second pending push parameter by the server. Flexible push method to better meet the user's actual experience needs.
  • the process of normally playing all the pieces in the media resource is taken as an example.
  • an application scenario in which the mediation is cancelled in the middle is also involved, for example, the user is halfway. If you don't want to continue watching, you need to cancel playing a certain shard and subsequent shards.
  • the client processes and plays the slice 3, and then cancels the playback of the slice 4 and the full-part slice after the slice 4 as an example.
  • FIG. 5 it is a cancellation provided by the embodiment of the present invention.
  • the flowchart of the method for pushing the media shards includes the steps S501-S510, wherein the steps S501-S506 can refer to the steps S401-S406 in the embodiment shown in FIG. 4, and details are not described herein again.
  • S507 The client sends a cancel push request message for the fragment 4 to the server.
  • the client may send a cancel push request message according to the stream identifier 6 of the fragment 4 recorded in the fragment list of the client that has sent the push commitment and is not pushed.
  • the server sends a cancel push request message for the slice 4 to the client as shown in the following code 12:
  • the error code CANCEL is used to indicate that the push fragment is canceled.
  • the client may further delete the identifier of the fragment 4 recorded in the fragment list of the client that has sent the push commitment and is not pushed, and the corresponding stream identifier.
  • S508 The server receives the cancel push request message sent by the client for the fragment 4, and cancels pushing the fragment 4 to the client.
  • the server determines that the client wants to cancel pushing the fragment corresponding to the stream identifier 6 http://example/rendition1/segment004 according to the stream identifier 6 carried in the cancel push request message, so the fragment 4 is pushed to the client. Specifically, the server deletes the identifier of the fragment 4 and the corresponding stream identifier from the fragment list of the server that has sent the push commitment and is not pushed.
  • S509 The client sends a cancel push request message for the fragment 5 to the server.
  • the client may send a cancel push request message according to the flow identifier 8 of the fragment 5 recorded in the fragment list of the client that has sent the push commitment and is not pushed.
  • the server sends a cancel push request message for the slice 5 to the client as shown in the following code 13:
  • the client may also delete the identifier of the fragment 5 recorded in the fragment list of the client that has been sent and not pushed, and the corresponding stream identifier.
  • the client has canceled all the shards that have sent the push promise and have not been pushed, and has cleared or deleted the client's sent push promised and unpushed shard list.
  • the client since the client does not continue to play media resources, the client also needs to clear or delete the pending push fragment list.
  • S510 The server receives the cancel push request message sent by the client for the fragment 5, and cancels pushing the fragment 5 to the client.
  • the server determines that the client wants to cancel pushing the fragment corresponding to the flow identifier 8 http://example/rendition1/segment005 according to the flow identifier 8 carried in the cancel push request message, so the fragment 5 is pushed to the client. Specifically, the server deletes the identifier of the fragment 5 and the corresponding stream identifier from the fragment list that has sent the push commitment and has not been pushed.
  • S511 The server determines that it is necessary to cancel the fragment that has not sent the push commitment to the client according to the server's sent push commitment and the unpushed fragment list is empty.
  • the server determines that the server has sent the push commitment and the un-pushed fragment list is empty, it is determined that the client does not want to continue playing the media resource, and therefore, the fragment that has not sent the push commitment is pushed to the client at the same time. Specifically, the server clears or deletes the pending push fragment list, so that the push commitment is not sent to the client yet. Fragmentation.
  • the server may indirectly determine to cancel the fragment that has not sent the push commitment to the client by canceling all the fragments that have been sent and not pushed by the client.
  • the server sends the push commitment of the fragment requested by the client to the client at one time. Therefore, when the client wants to cancel the fragment that the server has sent the push commitment, it needs to send for each fragment.
  • the push request message is canceled once, and the request message carries the flow identifier corresponding to the fragment to be cancelled.
  • the client needs to send a cancel push request message one by one for the slice that has been sent and not pushed. The cost is relatively large.
  • the server since the server sends the push commitment in batches, when the client cancels the play midway, only the cancel push request message needs to be sent one by one for the fragments that have been pushed and not pushed. There is no need to send a cancel push request message for a slice that has not yet sent a push commitment, which saves the overhead of the client sending a large number of cancel push request messages.
  • the client may also instruct the server to cancel pushing a fragment of the push commitment when canceling pushing a certain fragment by adding a cancellation pending push indication message to a cancel push request message.
  • the client sends the cancel push push indication information in the cancel push request message of the fragment 4 as an example.
  • the server sends the cancel push request message of the fragment 4 to the client as shown in the following code 14:
  • the error code CANCEL PENDING is used to indicate that the shard that has not yet sent the push promise is canceled.
  • the server cancels the fragment that has not sent the push commitment to the client, specifically: the server clears or deletes the pending push fragmentation list of the server.
  • the client may carry the cancel pending push indication information in a certain cancel push request message
  • the server determines, according to the cancel pending push indication information, that the fragment that has not yet sent the push commitment to be pushed to the client needs to be canceled.
  • the embodiment of the present invention can prevent the server from receiving the last one, as compared with the manner in which the server cancels the push of all the sent push promises that have not been pushed by the client, and indirectly determines the manner of canceling the push of the fragment that has not yet sent the push commitment to the client.
  • the server Before the cancel push request message of the slice that has been pushed and not pushed, the server has sent the push commitment corresponding to the pushable slice in the pending push slice to the client, so that the cancel operation is more timely.
  • the embodiment of the invention also describes a schematic structural diagram of a server under the same inventive concept as the method embodiment shown in FIG. 4 above.
  • the server 600 is configured to perform the functions of the server in the foregoing method embodiment of FIG. 4, and includes: a receiving unit 601, a processing unit 602, and a sending unit 603.
  • the receiving unit 601 is configured to receive a fragment request message sent by the client, where the fragment request message includes a request fragment identifier and a push instruction, where the push instruction is used to indicate that the client requests the pushed fragment;
  • the processing unit 602 is configured to determine, according to the slice that the client requests to push, the pushable slice and the pending push slice, and the sending unit 603 is configured to send, to the client, each of the pushable segments.
  • the processing unit 602 is configured to determine, according to the fragment that is sent by the client, the pushable fragment and the pending push fragment, where the client sends a request according to the first pending push parameter.
  • the shards are divided into the pushable shards and the to-be-scheduled shards; wherein the first pending push parameters are carried locally in the server or carried in the fragment request message.
  • the processing unit 602 is configured to divide, according to the first pending push parameter, the slice that the client requests to push into the pushable slice and the to-be-sent push slice, specifically:
  • the first pending push parameter is a push threshold, and determining that the first slice to the Nth slice of the slice that the client requests to push are the pushable slice, and the client requests the push.
  • the other fragments in the slice other than the pushable slice are determined as the pending push slice, where N is a positive integer determined by the push threshold; or
  • the first pending push parameter is a random indicator, and according to the random indicator, the cached slice in the slice that the client requests to push is determined as the pushable slice, and the client is The slice other than the pushable slice in the slice requested to be pushed is determined as the pending push slice.
  • the sending unit 603 sends, to the client, the push commitment corresponding to each fragment in the pushable fragment, the fragment corresponding to the requested fragment identifier, and the pending push indication information
  • the processing unit 602 is further configured to determine, according to the first pending push parameter, a pushable slice in the pending push slice;
  • the sending unit 603 is further configured to send, according to the second pending push parameter, a push commitment corresponding to the pushable slice in the to-be-sent push slice to the client, where the pending push slice is in the
  • the pushable fragment is a partial or full partial slice of the pending push slice; wherein the second pending push parameter is used to instruct the server to send the pushable in the pending push slice to the client
  • the conditions of the push commitment of the fragment, and the second pending push parameter is carried in the server or configured in the fragment request message.
  • the sending unit 603 is configured to send, according to the second pending push parameter, a push commitment corresponding to the pushable slice in the to-be-scheduled slice to the client, specifically:
  • the sending unit 603 sends, to the client, the push commitment corresponding to each fragment in the pushable fragment, the fragment corresponding to the requested fragment identifier, and the pending push indication information
  • the receiving unit 601 is further configured to receive, by the client, a cancel push request message that is sent one by one for the fragment that has sent the push commitment and is not pushed;
  • the processing unit 602 is further configured to cancel, according to the cancel push request message, a slice that is pushed to the client and that is not pushed, and when the processing unit 602 cancels all the Push the sent After the shard that is committed and not pushed, the processing unit 602 is further configured to cancel pushing the shard that has not sent the push commitment to the client.
  • the sending unit 603 sends, to the client, the push commitment corresponding to each fragment in the pushable fragment, the fragment corresponding to the requested fragment identifier, and the pending push indication information
  • the receiving unit 601 is further configured to receive a cancel push request message sent by the client for the target fragment, where the target fragment is any fragment that has sent a push commitment and is not pushed, and the cancel push request message
  • the canceling the push indication information is used to indicate that the server cancels pushing the shard that has not sent the push commitment to the client;
  • the processing unit 602 is further configured to cancel pushing the target fragment to the client according to the cancel push request message, and cancel pushing, to the client, a fragment that has not sent a push commitment.
  • server 600 is presented in the form of a functional unit.
  • a "unit” herein may refer to an ASIC circuit, a processor and memory that executes one or more software or firmware programs, integrated logic circuits, and/or other devices that provide the functionality described above.
  • server 600 can take the form shown in FIG.
  • the receiving unit 601, the processing unit 602, and the transmitting unit 603 can be implemented by the processor and memory of FIG.
  • the embodiment of the present invention further describes a structure of a client according to the same inventive concept as the method embodiment shown in FIG. 4 above.
  • the client 700 is configured to perform the functions of the client in the foregoing method embodiment of FIG. 4, including: a sending unit 701 and a receiving unit 702.
  • the sending unit 701 is configured to send a fragmentation request message to the server, where the fragmentation request message includes a request fragment identifier and a push instruction, where the push instruction is used to indicate that the client requests the pushed fragment; the receiving unit 702.
  • the device is configured to receive a push commitment corresponding to each of the shards sent by the server, a shard corresponding to the request shard identifier, and a pending push indication information, where the pending push indication information is used to indicate
  • the client waits to receive a push commitment of the pending push slice other than the pushable slice in the slice requested by the client.
  • the fragment request message further includes a first pending push parameter, where the first pending push parameter is used to instruct the server to send the fragment requested by the client according to the first pending push parameter. Divided into the pushable slice and the pending push slice.
  • the first pending push parameter includes a push threshold for indicating a number of pushable slices or a random indicator for indicating that the server determines the cached slice as a pushable slice.
  • the receiving unit 702 receives the push commitment corresponding to each of the pushable fragments sent by the server, the fragment corresponding to the requested fragment identifier, and the pending push indication information
  • the receiving unit 702 is further configured to receive a push commitment corresponding to the pushable slice in the to-be-sent push slice sent by the server, where the pushable slice in the pending push slice is the to-be-sent push score Part or all of the pieces in the film.
  • the fragment request message further includes a second pending push parameter, where the second pending push parameter is used to indicate that the server determines to send the pending push slice according to the second pending push parameter.
  • the conditions of the push commitment corresponding to the slice can be pushed.
  • the receiving unit 702 receives the push commitment corresponding to each of the pushable fragments sent by the server, the fragment corresponding to the requested fragment identifier, and the pending push indication information
  • the sending unit 701 is further configured to send, to the server, a cancel push request message, where the target fragment is any fragment that has sent a push commitment and is not pushed, and the cancel push request message includes Cancel pending push Instructing information, the cancel pending push indication information is used to instruct the server to cancel pushing a slice that has not sent a push commitment to the client.
  • client 700 is presented in the form of a functional unit.
  • a "unit” herein may refer to an ASIC circuit, a processor and memory that executes one or more software or firmware programs, integrated logic circuits, and/or other devices that provide the functionality described above.
  • client 700 can take the form shown in FIG.
  • the transmitting unit 701 and the receiving unit 702 can be implemented by the processor and the memory of FIG.
  • the embodiment of the present invention further provides a computer storage medium for storing computer software instructions used by the server shown in FIG. 6 above, which includes a program designed to execute the foregoing method embodiments.
  • the delivery of the push promise can be achieved by executing the stored program.
  • the embodiment of the present invention further provides another computer storage medium for storing computer software instructions used by the client described in FIG. 7 above, which includes a program designed to execute the foregoing method embodiments.
  • the reception of the push promise can be achieved by executing the stored program.
  • embodiments of the present invention can be provided as a method, apparatus (device), or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • the computer program is stored/distributed in a suitable medium, provided with other hardware or as part of hardware, or in other distributed forms, such as through the Internet or other wired or wireless telecommunication systems.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention concerne un procédé de poussée de fragments multimédia, un serveur et un client, le procédé comprenant : la réception, par un serveur, d'un message de demande de fragment envoyé par un client, le message de demande de fragment comprenant un identifiant de fragment demandé et une instruction de poussée, l'instruction de poussée étant utilisée pour indiquer un fragment demandé devant être poussé par le client ; la détermination, par le serveur, de fragments pouvant être poussés et de fragments de poussée à décider en fonction du fragment faisant l'objet d'une demande de poussés par le client ; et l'envoi, par le serveur, d'un engagement de poussée correspondant à chaque fragment dans les fragments pouvant être poussés, d'un fragment correspondant à l'identifiant de fragment demandé et d'informations d'indication de poussée à décider au client, les informations d'indication de poussée à décider étant utilisées pour ordonner au client d'attendre de recevoir des engagements de poussée pour les fragments de poussée à décider. L'adoption du procédé de la présente invention permet de réduire le retard de lecture d'un client.
PCT/CN2017/105714 2016-10-18 2017-10-11 Procédé de poussée de fragments multimédia, serveur et client WO2018072629A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610908973.4 2016-10-18
CN201610908973.4A CN107959667B (zh) 2016-10-18 2016-10-18 一种媒体分片的推送方法、服务器及客户端

Publications (1)

Publication Number Publication Date
WO2018072629A1 true WO2018072629A1 (fr) 2018-04-26

Family

ID=61954270

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/105714 WO2018072629A1 (fr) 2016-10-18 2017-10-11 Procédé de poussée de fragments multimédia, serveur et client

Country Status (2)

Country Link
CN (1) CN107959667B (fr)
WO (1) WO2018072629A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109660587A (zh) * 2018-10-22 2019-04-19 平安科技（深圳）有限公司 基于随机数的数据推送方法、装置、存储介质及服务器
CN114640711A (zh) * 2020-12-15 2022-06-17 深圳Tcl新技术有限公司 一种tlv数据包的推送方法、智能终端及存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111193684B (zh) * 2018-11-14 2021-12-21 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
CN111526379B (zh) * 2019-02-03 2021-06-29 华为技术有限公司 数据传输方法和数据传输装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7287087B1 (en) * 1999-11-01 2007-10-23 General Electric Company Communications network for dynamic reprioritization
CN104581374A (zh) * 2014-12-31 2015-04-29 深圳市同洲电子股份有限公司 一种获取切片文件和生成子m3u8文件的方法、节点及服务器
CN104918072A (zh) * 2014-03-14 2015-09-16 奥多比公司 低延时实况视频流传输
CN105532013A (zh) * 2013-07-12 2016-04-27 佳能株式会社 利用推送消息控制的自适应数据流传输方法
WO2016120089A1 (fr) * 2015-01-28 2016-08-04 Canon Kabushiki Kaisha Poussée améliorée de ressources entraînée par le client par un dispositif serveur
CN105979277A (zh) * 2016-04-25 2016-09-28 乐视控股（北京）有限公司 一种文件传输方法及电子设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7287087B1 (en) * 1999-11-01 2007-10-23 General Electric Company Communications network for dynamic reprioritization
CN105532013A (zh) * 2013-07-12 2016-04-27 佳能株式会社 利用推送消息控制的自适应数据流传输方法
CN104918072A (zh) * 2014-03-14 2015-09-16 奥多比公司 低延时实况视频流传输
CN104581374A (zh) * 2014-12-31 2015-04-29 深圳市同洲电子股份有限公司 一种获取切片文件和生成子m3u8文件的方法、节点及服务器
WO2016120089A1 (fr) * 2015-01-28 2016-08-04 Canon Kabushiki Kaisha Poussée améliorée de ressources entraînée par le client par un dispositif serveur
CN105979277A (zh) * 2016-04-25 2016-09-28 乐视控股（北京）有限公司 一种文件传输方法及电子设备

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109660587A (zh) * 2018-10-22 2019-04-19 平安科技（深圳）有限公司 基于随机数的数据推送方法、装置、存储介质及服务器
CN109660587B (zh) * 2018-10-22 2022-07-29 平安科技（深圳）有限公司 基于随机数的数据推送方法、装置、存储介质及服务器
CN114640711A (zh) * 2020-12-15 2022-06-17 深圳Tcl新技术有限公司 一种tlv数据包的推送方法、智能终端及存储介质
CN114640711B (zh) * 2020-12-15 2023-08-01 深圳Tcl新技术有限公司 一种tlv数据包的推送方法、智能终端及存储介质

Also Published As

Publication number Publication date
CN107959667B (zh) 2020-10-09
CN107959667A (zh) 2018-04-24

Similar Documents

Publication Publication Date Title
WO2018072629A1 (fr) Procédé de poussée de fragments multimédia, serveur et client
US9942340B2 (en) Scalable, real-time messaging system
US20180270317A1 (en) Unified end user notification platform
US9721616B2 (en) Playback of content pre-delivered to a user device
US20210337012A1 (en) File download manager
CN105933213B (zh) 一种聊天消息的处理方法、相关设备和系统
TWI590085B (zh) 用於硬體加速視頻系統中策略察知之裝置及方法
WO2015067117A1 (fr) Procédé et système de téléchargement vers le nuage, dispositif de planification et client
US20140324959A1 (en) Time-sensitive data delivery
WO2019128800A1 (fr) Procédé et dispositif de mise en œuvre de service de contenu, et nœud de réseau de distribution de contenu
CN110933517B (zh) 码率切换方法、客户端和计算机可读存储介质
JP2018532201A (ja) メッセージデータを転送するためのシステム及び方法
EP3734980A1 (fr) Terminal et procédé de lecture de vidéo, serveur et support d'informations
JP2019521576A (ja) メッセージングシステムの持続性の維持
TW201737675A (zh) 應用內容打包和傳送的訊號傳遞
GB2528672A (en) Push-based transmission of resources and correlated network quality estimation
JP2018531472A (ja) スケーラブルなリアルタイムメッセージングシステム
AU2012242421A1 (en) Data acquisition method, device and system
US20160029050A1 (en) Hybrid Stream Delivery
CN107920042B (zh) 一种直播间页面的优化传输方法和服务器
CN112565907A (zh) 视频获取方法、电子设备及存储介质
CN107920108A (zh) 一种媒体资源的推送方法、客户端及服务器
JP2016028470A (ja) クライアント端末と少なくとも１つのサーバーとの間の伝送経路内に設けられたキャッシュを動作させるための方法、および対応するキャッシュ
JP6342526B2 (ja) 生中継データを共有する方法およびシステム
US20160359946A1 (en) Techniques for promoting and viewing social content written by nearby people

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17863190

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17863190

Country of ref document: EP

Kind code of ref document: A1