WO2018072629A1

WO2018072629A1 - Media fragment push method, server and client

Info

Publication number: WO2018072629A1
Application number: PCT/CN2017/105714
Authority: WO
Inventors: 高莹; 顾迎节; 张尧烨
Original assignee: 华为技术有限公司
Priority date: 2016-10-18
Filing date: 2017-10-11
Publication date: 2018-04-26
Also published as: CN107959667B; CN107959667A

Abstract

Disclosed in the present invention are a media fragment push method, a server and a client, wherein the method comprises: receiving, by a server, a fragment request message sent by a client, the fragment request message comprising a requested fragment identifier and a push instruction, the push instruction being used to indicate a fragment requested to be pushed by the client; determining, by the server, pushable fragments and to-be-decided push fragments according to the fragment requested to be pushed by the client; and sending, by the server, a push commitment corresponding to each fragment in the pushable fragments, a fragment corresponding to the requested fragment identifier and to-be-decided push indication information to the client, wherein the to-be-decided push indication information is used to instruct the client to wait to receive push commitments for the to-be-decided push fragments. Adopting the method of the present invention can reduce the playback delay of a client.

Description

Pushing method, server and client for media segmentation

This application claims the priority of the Chinese patent application filed on October 18, 2016, the Chinese Patent Office, the application number is 201610908973.4, and the invention name is “a push method, server and client for media segmentation”. The citations are incorporated herein by reference.

Technical field

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.

Background technique

There are many ways for the client to obtain media resources and play them. Typical examples are: Hypertext Transfer Protocol (English: Hypertext Transfer Protocol, HTTP) file download or peer-to-peer (Peer to Peer, P2P) file download. Play to local disk, HTTP progressive download (English: HTTP Progressive Download) and 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. After obtaining the MPD, 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.

In order to reduce the client playback delay, part6:DASH with Server Push and WebSockets, which is being developed in the DASH standard (ISO-IEC_23009-6), proposes a push mechanism. Specifically, as shown in FIG. 1 , 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. 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. According to the step 5, 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.

Summary of the invention

The embodiment of the invention provides a method for pushing media fragments and related devices, which can reduce the playback delay of the client.

In a first aspect, 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. In the embodiment of the present invention, 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.

In a possible design, 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. In the embodiment of the present invention, 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.

In a possible design, 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. Where 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. In the embodiment of the present invention, 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.

In a possible design, after the server sends the push commitment corresponding to each fragment in the pushable fragment to the client, the fragment corresponding to the request fragment identifier, and the pending push indication information, 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. .

In the embodiment of the present invention, 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.

In a possible design, 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. When the remaining quantity is less than the first preset quantity, 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 When sharding, the server sends a push commitment corresponding to the pushable slice in the pending push shard to the client. In the embodiment of the present invention, 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.

In a possible design, after the server sends the push commitment corresponding to each fragment in the pushable fragment to the client, the fragment corresponding to the request fragment identifier, and the pending push indication information, 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. After the server cancels all shards that have been pushed to the client and have not been pushed, the server cancels pushing the shards that have not yet sent the push promise to the client. In the embodiment of the present invention, if 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.

In a possible design, after the server sends the push commitment corresponding to each fragment in the pushable fragment to the client, the fragment corresponding to the request fragment identifier, and the pending push indication information, 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.

In the embodiment of the present invention, 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.

In one possible design, 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.

In a possible design, after the server determines the pushable slice and the pending push slice according to the slice that the client requests to push, 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. After 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. By maintaining the second shard list, the server can clarify which shards have not yet sent push commitments.

In a possible design, the canceling the push request message carries the flow identifier, and 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.

In a second aspect, 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. In the embodiment of the present invention, 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. Compared with the prior art, 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.

In a possible design, 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. In the embodiment of the present invention, 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.

In one possible design, 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. In the embodiment of the present invention, 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.

In a possible design, 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. In the embodiment of the present invention, 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.

In a possible design, 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. Push the terms of the promise. In the embodiment of the present invention, 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.

In a possible design, 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. . In the embodiment of the present invention, when the remaining number of fragments that have been pushed and not pushed or the number of cached fragments of the server meet the preset condition, the client may receive the push commitment corresponding to the pending push fragment in time.

In a possible design, 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. In the embodiment of the present invention, if 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.

In a possible design, 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.

In a possible design, 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.

In a possible design, 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. By maintaining the first shard list, the client can clarify which shards that have sent push commitments have not been pushed.

In a possible design, 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. After the client receives the push commitment corresponding to the pushable fragment in the pending push fragment sent by the server, the method further includes: the client deleting the identifier corresponding to the pushable fragment in the pending push fragment from the second fragment list . By maintaining the second shard list, the client can clarify which shards have not yet sent push commitments.

In a possible design, 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.

In a third aspect, 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.

In one possible design, 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.

In a fourth aspect, 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.

In one possible design, 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.

In a fifth aspect, 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.

In a sixth aspect, 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.

According to a seventh aspect, 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. .

In an eighth 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.

According to a ninth aspect, 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.

By implementing the embodiment of the present invention, 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.

These and other aspects of the invention will be more apparent from the following description of the embodiments.

DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly described below.

1 is a schematic flow chart of a method for pushing a media slice in a conventional technology;

2 is a schematic structural diagram of a media slice pushing system according to an embodiment of the present invention;

3 is a schematic structural diagram of a computer device according to an embodiment of the present invention;

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.

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.

detailed description

The terms used in the embodiments of the present invention are only used to explain the specific embodiments of the present invention, and are not intended to limit the present invention. The technical solutions in the embodiments of the present invention will be clearly described below with reference to the accompanying drawings in the embodiments of the present invention.

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. Moreover, 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.

It should be noted that 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). In the system, the number of the clients 202 may also be multiple, which is not limited by the embodiment of the present invention. Specifically, the client 202 can be any terminal such as a mobile phone, a tablet computer, a desktop computer, or a notebook computer.

As shown in FIG. 3, 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.

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).

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.

In a particular implementation, as an embodiment, processor 301 may include one or more CPUs, such as CPU0 and CPU1 in FIG.

In a particular implementation, as an embodiment, 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. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data, such as computer program instructions.

In a particular implementation, as an embodiment, 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. For example, 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. For example, 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. In a specific implementation, 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.

Based on the schematic diagram of the system architecture described in FIG. 2, 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.

Specifically, 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. For the convenience of description, in the embodiment of the present invention, the client wants the server to push the shard 2, the shard 3, the shard 4, and the shard 5 as an example. In the embodiment of the present invention, the identifier of the fragment includes, but is not limited to, a uniform resource locator (English: Uniform Resoure Locator, abbreviated as: URL).

For example, the client sends a fragment request message carrying a push instruction to the server as shown in the following code 1:

Code 1

Where ":method=GET" indicates that the request method is GET and is used to obtain content. ":path=/example/rendition1/segment001" indicates the URL of the requested fragment (ie, the URL of the fragment 1 in the embodiment of the present invention), accept-push-policy="urn:mpeg:dash:fdh:2016:push -template"; "http://example/rendition1/segment{%03d}:{2-51}" means that the client wants the server to push the URL according to the URL template http://example/rendition1/segment{%03d} Slice 2 to slice 51 after slice 1, that is, push the URL address from http://example/rendition1/segment002 to 50 slices of http://example/rendition1/segment051.

It should be noted that only some parameters necessary in the fragment request message are listed here, and other parameters not related to the embodiment of the present invention are not listed here.

S402: 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.

Optionally, 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. Causes 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.

For example, if the first pending push parameter is that the maximum number of push commitments sent at one time is four, 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) is determined to be a pushable slice, and the remaining 46 slices are determined as pending push slices. Alternatively, when the first pending push parameter is a random indicator, 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.

Specifically, the push commitment indicates that the server will push the fragment in the stream indicated by the stream ID. In the embodiment of the present invention, the server sends a push commitment for the slice 2, the slice 3, the slice 4, and the slice 5 respectively. Moreover, these four push commitments are sent to the client before sending the fragment 1. In a specific implementation, 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. For example, the server sends push commitments and shards 1 to the client as shown in the following code 2-6:

Code 2 slice 2 push promise

Code 3 slice 3 push promise

Code 4 slice 4 push promise

Code 5 Fragment 5 Push Commitment

Code 6 slice 1

As shown in the code 2, "Stream ID=1" indicates that the current message body is transmitted in the stream with Stream ID=1, and "Stream ID=2" indicates that the server will push the fragment 2 in the stream with StreamID=2," :path=/example/rendition1/segment002" indicates the URL of slice 2. Codes 3-5 are similar to the format of Code 2 and will not be explained here. The message format of the fragment 1 of the server sending the client request is as shown in the code 6, where "status=200" indicates that the server has successfully processed the fragment request message of the client, push-policy="urn:mpeg:dash:fdh :2016:push-template"; "http://example/rendition1/segment{%03d}:{2-5}" means that the server's push policy this time is to push slice 2 to slice 5. In another possible design, you can also set the push-policy to "urn:mpeg:dash:fdh:2016:push-template"; http://example/rendition1/segment{%03d}:{2- 51}, indicating that the server accepts the push request of the client, and can determine that the slice 2 to the slice 51 after the slice 1 can be pushed. The "pending-push=true" is a pending push indication information, which indicates that the server will send a push commitment to the push shard (ie, the shard 6 to the shard 51 in this example), and the push indication information is to be determined in the embodiment of the present invention. 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.

It should be noted that, in the embodiment of the present invention, the HEADERS frame in which the server pushes the pending push indication information in the returned response message is taken as an example. In other implementable manners, 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.

Optionally, 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. For example, after the server divides the fragment requested by the client into pushable fragments and pending push fragments, the server sends a push commitment for each pushable fragment to the client. In this example, after 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. For example, 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

分片的标识Fragment identification	流标识Flow identification
http://example/rendition1/segment002Http://example/rendition1/segment002	22
http://example/rendition1/segment003Http://example/rendition1/segment003	44
http://example/rendition1/segment004Http://example/rendition1/segment004	66
http://example/rendition1/segment005Http://example/rendition1/segment005	88

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.

For example, the format of the pending push slice list can be as shown in Table 2.

Table 2 list of pending push fragments

分片的标识Fragment identification
http://example/rendition1/segment006Http://example/rendition1/segment006
http://example/rendition1/segment007Http://example/rendition1/segment007
……......
http://example/rendition1/segment051Http://example/rendition1/segment051

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.

Specifically, 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.

Afterwards, 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.

After that, 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.

In the embodiment of the present invention, the server pushes the fragment 2 to the client through the stream of StreamID=2. For example, the server is The client sends the fragment 2 as shown in the following code 7:

Code 7 slice 2

After 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.

In the embodiment of the present invention, after receiving the response message corresponding to the fragment 2, the client determines that the data of the fragment 2 is received according to the StreamID=2 carried in the response message, and then processes and plays the fragment 2.

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.

Optionally, after receiving the response message corresponding to the fragment 2, the client may further determine whether the response message includes a push commitment.

Then, 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. For the process, reference may be made to step S405 and step S406, and details are not described herein again. Each time 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. 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.

S407: The server determines a pushable slice in the pending push slice.

Optionally, 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. For example, if the first pending push parameter is the maximum number of push commitments sent at one time, 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. Alternatively, when the first pending push parameter is a random indicator, 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.

Specifically, 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.

For example, when the remaining number of shards that have been sent and not pushed is less than two, it is determined that 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.

Alternatively, if 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.

In this embodiment, 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.

It should be noted that 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:

Code 8 slice 5

As shown in 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.

Optionally, when the server sends the fragment 5 to the client, 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:

Code 9 slice 5

The "pending-push=true" is the pending push indication information, indicating that the server subsequently sends a push commitment to the remaining fragments that have not yet sent the push commitment (ie, the fragment 10 to the fragment 51 in this example).

In addition, 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. In 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. .

It should be noted that 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.

S409: 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.

Thereafter, the client processes and plays the slice 5 and waits for the slice 6 to slice 9 pushed by the receiving server.

Optionally, if the server sends the pending push indication information, 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.

It should be noted that, before step S410, steps S407 to S409 are repeated between the server and the client until the condition of step S410 is satisfied. In this embodiment, 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.

It should be noted that, if other fragments are still present after the fragment 51 and the client wishes to continue playing the partial fragment, the 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.

By implementing the embodiment of the present invention, 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.

According to the prior art, if the number of fragments on the server that can send push commitments is less than the number of fragments that the client requests to push, the server can only send push commitments for fragments that can send push commitments, even if a push commitment can be sent. 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. In the embodiment of the present invention, 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.

In a possible design, 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.

For example, the client sends a fragment request message carrying the first pending push parameter to the server as shown in the following code 10:

Code 10

Among them, maxTotalNum=5 is the first pending push parameter, that is, the maximum number of pushable fragments that the client wants the server to immediately send the push promise is five.

In a possible design, 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 For the manner, refer to the description of step S407 above, and details are not described herein again.

For example, 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.

It should be noted that if the server is configured with the first pending push parameter locally, 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.

For the step S403, when the server sends the fragment 1 to the client, the server may further carry the first pending push parameter and/or the second pending push parameter. For example, the server sends a slice 1 to the client as shown in code 11:

Code 11 slice 1

The pending-push-policy=“maxTotalNum=5&latestPush” is the pending push indication information, which is used to indicate that the client waits to receive the push commitment corresponding to the other fragments that have not sent the push commitment, and indicates that the client server actually uses the first 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.

In the embodiment of the present invention, 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.

In the above embodiment, the process of normally playing all the pieces in the media resource is taken as an example. In the actual application, in addition to playing a complete media resource normally, 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. In this scenario, 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. Referring to FIG. 5, it is a cancellation provided by the embodiment of the present invention. The flowchart of the method for pushing the media shards, the process 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.

Specifically, 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. For example, the server sends a cancel push request message for the slice 4 to the client as shown in the following code 12:

Code 12 slice 4 cancel push request message

Among them, the error code CANCEL is used to indicate that the push fragment is canceled.

Optionally, after determining that the push fragment 4 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.

Specifically, 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. For example, the server sends a cancel push request message for the slice 5 to the client as shown in the following code 13:

Code 13 slice 5 cancel push request message

Optionally, after determining that the push fragment 5 is canceled, 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.

At this point, 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.

In addition, 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.

At this point, the server's sent push commitments and the unpushed fragment list are empty.

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.

Specifically, after 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.

In the embodiment of the present invention, 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.

In the prior art, 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. When a user watches a movie, if the server has sent a lot of push commitments, but the user suddenly does not want to continue watching, 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. In the embodiment of the present invention, 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.

In addition, 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 format of the canceling the push indication information is not specifically limited in the embodiment of the present invention. At this point, you need to define a new status code, Error Code=CANCEL PENDING, which is an example and not a limitation. 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:

Code 14 slice 4 cancel push request message

Among them, the error code CANCEL PENDING is used to indicate that the shard that has not yet sent the push promise is canceled.

After receiving the cancel push request message with the error code CANCEL PENDING, the server not only needs to cancel the push of the fragment corresponding to STREAM ID=6, http://example/rendition1/segment004, but also cancels pushing the push promise to the client. Fragmentation.

Specifically, 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.

In the embodiment of the present invention, the client may carry the cancel pending push indication information in a certain cancel push request message, and 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. 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. As shown in FIG. 6, 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 push commitment corresponding to the slice, the fragment corresponding to the request fragment identifier, and the pending push indication information, where the pending push indication information is used to indicate that the client waits to receive the push commitment of the pending push slice.

Optionally, 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.

Optionally, 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.

Optionally, after 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.

Optionally, 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:

Sending, to the client, a push commitment corresponding to the pushable slice in the to-be-sent push slice when the remaining number of the shards that have been pushed and not pushed is less than the first preset number; or

And sending, to the client, a push commitment corresponding to the pushable slice in the to-be-sent push slice, when the to-be-scheduled push slice includes the cached slice that meets the second preset number.

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 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.

In the present embodiment, the 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. In a simple embodiment, those skilled in the art will appreciate that 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. As shown in FIG. 7, 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.

Optionally, 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.

Optionally, 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.

Optionally, after 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.

Optionally, 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 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.

In this embodiment, 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. In a simple embodiment, those skilled in the art will appreciate that 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.

Although the present invention has been described herein in connection with the embodiments of the present invention, it will be understood by those skilled in the <RTIgt; Other variations of the disclosed embodiments are achieved. In the claims, the <RTI ID=0.0>"comprises" </ RTI> </ RTI> does not exclude other components or steps. A single processor or other unit may fulfill several of the functions recited in the claims. Certain measures are recited in mutually different dependent claims, but this does not mean that the measures are not combined to produce a good effect.

Those skilled in the art will appreciate that 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 present invention has been described with reference to flowchart illustrations and/or block diagrams of the methods, apparatus, and computer program products of the embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

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.

While the invention has been described with respect to the specific embodiments and embodiments thereof, various modifications and combinations may be made without departing from the spirit and scope of the invention. Accordingly, the specification and drawings are only attached The exemplifications of the present invention are intended to be illustrative, and are intended to cover any and all modifications, variations, It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and modifications of the invention

Claims

A method for pushing a media slice, characterized in that it comprises:

Receiving, by the server, a fragmentation request message sent by the client, 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;

Determining, by the server, the pushable slice and the pending push slice according to the slice that the client requests to push;

The server sends, to the client, a push commitment corresponding to each of the shards, 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.
The method according to claim 1, wherein 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 fragment that the client requests to push into the pushable fragment and the pending push fragment according to the first pending push parameter; wherein the first pending push parameter is the server local configuration Or carried in the fragment request message.
The method according to claim 2, wherein the server divides the slice that the client requests to push into the pushable slice and the pending push slice according to the first pending push parameter, specifically :

The first pending push parameter is a push threshold, and the server determines that the first slice to the Nth slice of the slice that the client requests to push are the pushable slice, and the client is The other pieces of the slice requested to be pushed except 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 the server determines, according to the random indicator, the cached slice in the slice that the client requests to push as the pushable slice, and The slice other than the pushable slice in the slice requested by the client is determined as the pending push slice.
The method according to any one of claims 1 to 3, wherein the server sends, to the client, a push commitment corresponding to each fragment of the pushable fragment, and the request fragment identifier corresponds to After the sharding and pending push instructions, it also includes:

Determining, by the server, the pushable fragments in the pending push slice according to the first pending push parameter;

Sending, by the server, a push commitment corresponding to the pushable slice in the to-be-scheduled slice to the client according to the second pending push parameter, where the pushable slice in the pending push slice is the to-be-determined Pushing a partial or full partial slice in the slice; wherein the second pending push parameter is used to instruct the server to send, to the client, a condition of a push commitment of the pushable slice in the pending push slice, And the second pending push parameter is carried locally in the server or carried in the fragment request message.
The method according to claim 4, wherein the server sends a push commitment corresponding to the pushable slice in the pending push slice to the client according to the second pending push parameter, specifically:

Determining that the remaining number of the shards that have been sent and not pushed is less than the first preset number, the server sends the push commitment corresponding to the pushable shards in the pending push shards to the client; or

Determining that the pending push slice includes a cached slice that meets a second preset number, and the server sends a push commitment corresponding to the pushable slice in the pending push slice to the client.
The method according to any one of claims 1 to 5, wherein the server sends a push commitment corresponding to each fragment of the pushable fragment to the client, and the request fragment identifier corresponds to After the sharding and pending push instructions, it also includes:

Receiving, by the server, a cancel push request message sent by the client one by one for a fragment that has sent a push commitment and is not pushed;

The server cancels, according to the cancel push request message, a slice that has pushed the pushed push commitment and is not pushed to the client;

After the server determines to cancel all the shards that have pushed the sent push commitment to the client and has not pushed, the server cancels pushing the shard that has not sent the push commitment to the client.
The method according to any one of claims 1 to 5, wherein the server sends a push commitment corresponding to each fragment of the pushable fragment to the client, and the request fragment identifier corresponds to After the sharding and pending push instructions, it also includes:

The server receives the cancel push request message sent by the client for the target fragment, where 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, 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;

The server cancels pushing the target shard to the client according to the cancel push request message, and cancels pushing the shard that has not sent the push commitment to the client.
A method for pushing a media slice, characterized in that it comprises:

The client sends 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 client receives 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 a pending push slice, wherein the pending push slice is a slice other than the pushable slice in the slice that the client requests to push.
The method according to claim 8, wherein the fragment request message further includes a first pending push parameter, wherein the first pending push parameter is used to indicate that the server is to be based on the first pending push parameter The slice requested by the client is divided into the pushable slice and the pending push slice.
The method according to claim 9, wherein said first pending push parameter comprises a push threshold for indicating a number of pushable slices or for instructing said server to determine a cached slice as a pushable score A random indicator of the slice.
The method according to any one of claims 8 to 10, wherein the client receives the server After the push commitment corresponding to each of the sent shards, the shard corresponding to the request shard identifier, and the pending push indication information, the method further includes:

Receiving, by the client, a push commitment corresponding to the pushable slice in the pending push slice sent by the server, where the pushable slice in the pending push slice is part of the pending push slice or Full part of the film.
The method according to claim 11, wherein the fragment request message further includes a second pending push parameter, wherein the second pending push parameter is used to instruct the server to determine according to the second pending push parameter. Sending a condition of the push commitment corresponding to the pushable slice in the pending push slice.
The method according to any one of claims 8 to 12, wherein the client receives a push commitment corresponding to each of the shards sent by the server, and the request fragment identifier corresponds to After the sharding and the pending push information, it also includes:

The client sends a cancel push request message to the server 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 includes canceling the pending push indication information. And the cancel pending push indication information is used to instruct the server to cancel pushing the fragment that has not sent the push commitment to the client.
A server, comprising:

a receiving unit, configured to receive a fragmentation request message sent by the client, 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;

a processing unit, configured to determine a pushable slice and a pending push slice according to the slice that the client requests to be pushed;

a sending unit, configured to send, to the client, a push commitment corresponding to each fragment of the pushable fragment, a fragment corresponding to the requested fragment identifier, and a pending push indication information, where the pending push indication information is used And instructing the client to wait for receiving the push commitment of the pending push slice.
The server according to claim 14, wherein the processing unit is configured to determine a pushable slice and a pending push slice according to the slice that the client requests to push, specifically:

Dividing the fragment that the client requests to push into the pushable fragment and the pending push fragment according to the first pending push parameter; wherein the first pending push parameter is locally configured or The fragmentation request message is carried in the message.
The server according to claim 15, wherein the processing unit 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 The film is 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.
A server according to any one of claims 13 to 16, wherein said transmitting unit is said to said After the client sends 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 is further configured to determine, according to the first pending push parameter, a pushable slice in the pending push slice;

The sending unit is further 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, where the pending push slice can be Pushing a slice into a partial or full-part slice in the to-be-scheduled slice; wherein the second pending push parameter is used to instruct the server to send the pushable segment in the pending push slice to the client The condition of the push commitment of the slice, and the second pending push parameter is carried in the server locally configured or in the fragment request message.
The server according to claim 17, wherein the sending unit is configured to send, according to the second pending push parameter, a push commitment corresponding to the pushable slice in the pending push slice to the client ,Specifically:

Sending, to the client, a push commitment corresponding to the pushable slice in the to-be-sent push slice when the remaining number of the shards that have been pushed and not pushed is less than the first preset number; or

And sending, to the client, a push commitment corresponding to the pushable slice in the to-be-sent push slice, when the to-be-scheduled push slice includes the cached slice that meets the second preset number.
The server according to any one of claims 14 to 18, wherein the sending unit sends, to the client, a push commitment corresponding to each of the shardable fragments, the request fragmentation After identifying the corresponding shard and the pending push indication information,

The receiving unit is further configured to receive a cancel push request message sent by the client one by one for a slice that has sent a push commitment and is not pushed;

The processing unit 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 cancels all push to the client After the fragment that has sent the push commitment and is not pushed, the processing unit is further configured to cancel pushing the fragment that has not sent the push commitment to the client.
The server according to any one of claims 14 to 18, wherein the sending unit sends, to the client, a push commitment corresponding to each of the shardable fragments, the request fragmentation After identifying the corresponding shard and the pending push indication information,

The receiving unit 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 is The canceling the push indication information is used to indicate that the server cancels pushing the fragment that has not sent the push commitment to the client;

The processing unit is further configured to cancel pushing the target fragment to the client according to the cancel push request message, and cancel pushing a fragment that has not sent a push commitment to the client.
A client, comprising:

a sending unit, 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;

a receiving unit, configured to receive a push commitment corresponding to each of the shards sent by the server, and the And the pending push indication information is used to indicate that the client waits to receive a push commitment of the pending push slice, where the pending push slice is the client A slice other than the pushable slice in the slice requested to be pushed.
The client according to claim 21, wherein the fragment request message further includes a first pending push parameter, and the first pending push parameter is used to instruct the server to perform the first pending push parameter according to the first pending push parameter. Dividing the slice requested by the client into the pushable slice and the pending push slice.
The client according to claim 22, wherein said first pending push parameter comprises a push threshold for indicating a number of pushable slices or for instructing said server to determine a cached slice as pushable A random indicator of the slice.
The client according to any one of claims 21 to 23, wherein the receiving unit receives a push commitment corresponding to each of the pushable fragments sent by the server, and the request fragment identifier After the corresponding shard and the pending push indication information,

The receiving unit 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 pending push slice Part or all of the pieces.
The client according to claim 24, wherein the fragment request message further includes a second pending push parameter, and the second pending push parameter is used to instruct the server to perform the second pending push parameter according to the second pending push parameter. Determining a condition for transmitting a push commitment corresponding to the pushable slice in the pending push slice.
The client according to any one of claims 21 to 25, wherein the receiving unit receives a push commitment corresponding to each of the pushable fragments sent by the server, and the request fragment identifier After the corresponding shard and the pending push indication information,

The sending unit is further configured to send a cancel push request message to the server 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 includes cancellation. Pending push indication 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.