WO2011150644A1

WO2011150644A1 - Method and apparatus for acquiring and transmitting streaming media data in the process of initiation

Info

Publication number: WO2011150644A1
Application number: PCT/CN2010/079939
Authority: WO
Inventors: 代金良; 冯江平; 张军; 许志勇
Original assignee: 华为技术有限公司
Priority date: 2010-12-17
Filing date: 2010-12-17
Publication date: 2011-12-08
Also published as: CN102656857A; CN102656857B

Abstract

A method and an apparatus for acquiring and transmitting streaming media data in the process of initiation are provided in the embodiments of the present invention. The acquiring method includes: acquiring a streaming media content description file (101); generating an acquiring request for the segment content according to the streaming media content description file and transmitting it to the server end (102); acquiring the streaming media data segment content corresponding to the acquiring request for the segment content from the server by using multiple Transmission Control Protocol (TCP) connections in the process of initiation (103). The embodiments of the present invention can reduce the initiation delay.

Description

Streaming media data acquisition and transmission method and device in startup phase

The present invention relates to the field of streaming media technologies, and in particular, to a method and an apparatus for acquiring and transmitting streaming media data in a startup phase. Background technique

The Smooth Streaming mechanism is a streaming media service based on the HTTP (Hyper Text Transfer Protocol) protocol. It can adaptively change the transmission rate according to the network conditions to achieve smooth playback of the terminal. . In this technology, the video content is bounded by a complete GOP (Group of Pictures), one GOP or multiple GOPs are encapsulated into one fragment, and the same code rate fragment is encapsulated into a segment. . The encapsulated audio and video files are stored on the HTTP web server. The client uses the HTTP protocol to request the corresponding audio and video fragments from the fragment, and plays them. When the user watches, it is like watching traditional streaming media (such as RTSP ( Real Time). Streaming Protocol, Real Time Messaging Protocol, RTMP (Real Time Messaging Protocol). Specifically, when the user views the video through the Smooth Streaming, the message flow between the client and the server mainly includes the following steps: i. The player downloads the Manifest file: the Manifest file describes the audio and video bit rate of the requested media content, Information such as coding, fragmentation rules, etc. Subsequent request for audio and video data by the player on a piecemeal basis depends on the file. Ii. The player requests audio and video data piece by piece, and decodes the presentation: The client parses the received manifest file, and generates a URL of each fragment request of the audio and video content according to the fragmented URL template given in the manifest file. The URL of the fragment request must carry the information of the bit rate, the fragment start position, and the media type. The server parses the bit rate in the HTTP request message, the fragment start position, and the media type, and finds the corresponding content, through HTTP. The protocol responds to the client. The specific request for which bit rate file, the player can be determined based on the detected actual network bandwidth and client processing capabilities. Corresponding to the Smooth Streaming mechanism is Dynamic Streaming. It is also a streaming media service based on the HTTP protocol. It can adaptively change the transmission bit rate according to the network conditions, so as to achieve smooth playback of the terminal. In this technology, the video content is bounded by a complete GOP, and one GOP or multiple GOPs are encapsulated into one fragment, and the same fragment with the same encoding rate and number of GPs is encapsulated into one segment. The encapsulated audio and video files are stored on the HTTP web server. The client uses the HTTP protocol to request the corresponding audio and video fragments from the fragment, and plays them. When the user watches, it is like watching traditional streaming media (such as RTSP, RTMP). . Specifically, when a user views a video through Dynamic Streaming, the message flow between the client and the server mainly includes the following steps: i. The player downloads the f4m file: The file describes the audio and video bit rate and encoding of the requested media content. , fragmentation rules and other information. Subsequent request for audio and video data by the player on a piecemeal basis depends on the file. Ii. Player downloads the bootstrap file: This file describes the metadata information of each fragment segment, and the file can exist independently or merge with the f4m file. Iii. The player requests audio and video data piece by piece, and decodes and presents: The client parses the received f4m file and the bootstrap file, generates a tone according to the fragment URL template given in the f4m file, and the metadata information in the bootstrap file. The URL of each fragment request for video content. The bit rate and the fragment index information are carried in the URL of the fragment request, and the server side parses the bit rate in the HTTP request message, and finds the corresponding content according to the fragment index, and responds to the client through the HTTP protocol. The specific request for which bit rate file, the player can be determined based on the detected actual network bandwidth and client processing capabilities.

In the Smooth Streaming scheme, the total startup delay is composed of the manifest delay of the manifest and the padding delay of the decoding buffer. In the Dynamic Streaming scheme, the total startup delay is delayed by the delivery of the f4m file and the bootstrap file. The padding delay of the decoding buffer is composed. The padding delay of the decoding buffer is affected by the buffer size and the sending speed of the media content in the startup phase. In order to reduce the startup delay and enhance the user's viewing experience, the player uses two methods of starting and setting a smaller buffer at the lowest bit rate. For example, when the server provides content at 512kbps, 1Mbps, and 2Mbps, the player is in the startup phase, and the fixed request is 512kbps. Content.

In the process of implementing the present invention, the inventors have found that at least the following problems exist in the prior art:

In the Smooth Streaming scheme and the Dynamic Streaming scheme, although the startup delay is attempted, due to some limitations in the actual application, the startup delay is still large when the scheme is actually used. For example, the access bandwidth of broadband in most cities in China is lower than 2 Mbps. Assume that the calculation is performed at 2 Mbps. Because the number and duration of each shard are described in the manifest file, the file is too large, a 100-minute period. The movie, its manifest file is generally around 500kB, which means that only downloading the manifest file may take about 2s, when the buffer is set to 2, each slice is 2s (recommended value), the lowest bit rate is 512kbps, the first 2 The theoretical download delay of the slice media slice is I s , that is to say, in this case, the start delay is not less than 3s o. In fact, there is a contention between users in the cell local area network (essentially the bottom layer). The bandwidth of the transmission protocol, such as TCP and UDP, causes the actual bandwidth used by the user to be lower or lower than its subscription bandwidth. This means that the delay in downloading the manifest file and filling the media fragment file of the buffer will actually be more Big. On the server side, in order to improve the concurrent service capability of the HTTP server, the operator often limits the connection bandwidth of the server, which also affects the delivery speed of the streaming media data. In addition, when the user encounters an uninteresting part during the viewing process, it often jumps directly to the back view. After the jump occurs, if the content of the new location has not been downloaded to the local, the same is faced with the padding delay of the decoding buffer. The technology directly requests the lowest bit rate to reduce the padding delay. As a result, the user may find that the quality of the video it watches after the jump is significantly degraded, which obviously affects the user's viewing experience. Summary of the invention

Embodiments of the present invention provide a method and an apparatus for acquiring and transmitting streaming media data in a startup phase to reduce startup delay.

In one aspect, the embodiment of the present invention provides a method for acquiring streaming media data in a startup phase, where the method includes: acquiring a streaming media content description file; and generating a file according to the streaming media content description file. The component content acquisition request is sent to the server; the multiple transmission control protocol is utilized during the startup phase.

And the TCP connection, the fragmented content of the streaming media data corresponding to the fragment content acquisition request is obtained from the server end.

On the other hand, the embodiment of the present invention provides a method for transmitting streaming media data in a startup phase, where the method includes: sending a streaming media content description file; and receiving, by the receiving client, the fragment content obtained according to the streaming media content description file. Requesting; using a plurality of transmission control protocol TCP connections in the startup phase, transmitting the fragmented content of the streaming media data corresponding to the fragmentation content acquisition request.

In another aspect, an embodiment of the present invention provides a client device for acquiring streaming media data in a startup phase, where the client device includes: an acquiring unit, configured to acquire a streaming media content description file; and a request generating unit, configured to The streaming media content description file is generated, and the generated fragmentation content acquisition request is sent to the server. The acquiring unit is further configured to use multiple transmission control protocols in the startup phase.

In a further aspect, the embodiment of the present invention provides a server device for sending streaming media data in a startup phase, where the server device includes: a sending unit, configured to send a streaming media content description file; and a request receiving unit, configured to receive the client And the sending unit is further configured to: use the multiple transmission control protocol TCP connection in the startup phase to send the streaming media data corresponding to the fragmented content acquisition request Fragment content.

The above technical solution has the following beneficial effects: Since the fragmentation content of the streaming media data of the startup phase is transmitted or acquired by using a plurality of transmission control protocol TCP connections in the startup phase, the technical effect of reducing the startup delay is achieved. DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the prior art description will be briefly described below, obviously, the following The drawings in the description are only some of the embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive labor.

1 is a flowchart of a method for acquiring streaming media data in a startup phase according to an embodiment of the present invention; FIG. 2 is a flowchart of a method for transmitting streaming media data in a startup phase according to an embodiment of the present invention; FIG. 3 is a flowchart of a Smooth Streaming message according to an embodiment of the present invention; FIG. 4 is a schematic flowchart of a message exchange of a message of a Smooth Streaming according to an embodiment of the present invention; FIG. 5 is a schematic flowchart of another message interaction of a Smooth Streaming according to an embodiment of the present invention; FIG. 6 is a schematic diagram of a non-uniform sharding mechanism according to an embodiment of the present invention; Schematic diagram of the fragmented content of the generated streaming media data in the startup phase;

FIG. 7 is a schematic structural diagram of a client device for acquiring streaming media data in a startup phase according to an embodiment of the present invention; FIG.

FIG. 8 is a schematic structural diagram of a server device for transmitting streaming media data in a startup phase according to an embodiment of the present invention. detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

In the existing Transmission Control Protocol (TCP) mechanism, when a client requests a single fragment file

Both the HTTP request message and the response message corresponding to the server are established on a single TCP connection. This causes the client to obtain a large amount of fragmentation content of the streaming media data during the startup phase, resulting in a significant degradation in video quality, which in turn affects the user's viewing experience. In view of this, the embodiment of the present invention uses a plurality of transmission control protocol TCP connections in the startup phase to acquire the fragmentation content of the streaming media data in the startup phase, thereby reducing the startup delay.

As shown in FIG. 1 , a flow of a method for acquiring streaming media data in a startup phase according to an embodiment of the present invention is shown. The method includes:

101. Obtain a streaming media content description file.

Optionally, the obtaining the streaming media content description file includes: obtaining the streaming media content description file compressed by the Hypertext Transfer Protocol HTTP protocol, or acquiring the streaming media content description file in segments.

102. Generate a fragmentation content acquisition request and send it to the server according to the streaming media content description file.

Optionally, before sending the fragment content acquisition request, determining that the current phase is in a startup phase.

Optionally, according to the playable time T of the received media content in the local receiving buffer, the lowest code rate br of the requested media content, the estimated network transmission bandwidth w, the duration t of the previous fragment, a predetermined decision Threshold THD0, determines if it is currently in the startup phase. The specific judgment algorithm is as follows:

If T+w*t/br<THD0, it is currently in the startup phase;

Otherwise, the startup phase ends.

103. The multiple-transmission control protocol TCP connection is used in the startup phase, and the fragment content of the streaming media data corresponding to the fragment content acquisition request is obtained from the server end.

Optionally, the step may include: a. obtaining, by using a streaming media content description file, a fragment length of the streaming media data in the startup phase, or acquiring the content by using a header (HEAD) method in HTTP 1.1. The fragmentation length of the streaming media data in the startup phase, or the fragmentation length of the streaming media data in the startup phase is obtained through the extended query field in the URL of the HTTP request message; b, according to the fragment length, the concurrent super The text transmission protocol HTTP message, and the server end establishes a plurality of transmission control protocol TCP connections, which may be: using HTTP Range-Request or in the URL of the HTTP request message, using the extended query field method to establish concurrent HTTP The request, the concurrent HTTP requests may be sent to the same server, or may be sent to different servers, and each HTTP request corresponds to a TCP connection, so that the multiple transmission control protocol TCP connections are established; c. Multiple transport control protocol TCP connections, points The segment simultaneously acquires the slice content of the streaming media data corresponding to the fragment content acquisition request. During the startup phase, the server may use a uniform length for the fragment length, or adjust the fragment length interval gradually during the startup phase: If the network condition is detected to be excellent, the fragment length is increased step by step. If the network condition is detected to be poor, the slice length is gradually reduced. For example, set

The code rate of the requested previous sliced media content is br, the average transmission bandwidth of the previous sliced media content is w, and the number of segments of the previous slice is s, if s<2, let s=2. Assume that THD1 and THD2 are two decision thresholds respectively, which are used to indicate the pros and cons of network conditions:

If w*/br>THDl, the number of segments of the current slice is s-1;

If w*/br<THD2, the number of segments of the current slice is s+1;

Otherwise, the current number of fragments is still 8.

Optionally, after the acquiring the fragmented content of the streaming media data in the startup phase, the method further includes: parsing the fragmented content of the streaming media data in the startup phase, presenting the first frame video image, and then The display remains in the playback window until the buffer data meets the requirements for subsequent smooth playback.

The method for acquiring the streaming media data in the startup phase provided by the embodiment of the present invention uses a plurality of transmission control protocol TCP connections to obtain the fragmented content of the streaming media data in the startup phase, thereby achieving the technical effect of reducing the startup delay.

As shown in FIG. 2, it is a flowchart of a method for sending streaming media data in a startup phase according to an embodiment of the present invention, where the method includes:

201. Send a streaming media content description file.

Pre-processing: Before providing streaming services through the server, operators often need to convert multimedia content into a specific format. In particular, in the business scenario of Smooth Streaming, multimedia content must first be converted into at least logically fragmentable. File format, this is preprocessing. In order to reduce the playback start delay of the client, in the pre-processing, for the multimedia content of the previous part, the fragment length is shorter, and the fragment length of the latter part is normal.

Optionally, the sending the streaming media content description file includes: sending the streaming media content description file compressed by a hypertext transfer protocol HTTP protocol, or sending the streaming media content in segments Description file.

202. The receiving client obtains a request for the fragmented content sent according to the streaming media content description file.

203. Send, by using multiple transport control protocol TCP connections in the startup phase, the fragment content of the fragmented content to obtain the fragmented content of the streaming media data corresponding to the request.

Optionally, before sending the content requested by the client, it is estimated whether the client is currently in the startup phase.

Optionally, detecting, according to the request message of the client, whether the client is in a startup phase: if the HTTP request message carries a Range-Request header field, the content of the request is part of the fragment, or the URL of the HTTP request message. Using the query field to extend a request for a portion of the data in the shard indicates that the client is currently in the startup phase.

Optionally, the sending, by using the multiple connection control protocol TCP connection, the fragmentation content of the streaming media data corresponding to the fragmentation content acquisition request, including: before sending the content corresponding to the fragment content acquisition request of the client Determining that the client is currently in a startup phase; in the startup phase, establishing, by the client, the plurality of transmission control protocol TCP connections by using a concurrent hypertext transfer protocol HTTP message; using the multiple transmission control protocol TCP The segmentation content of the streaming media data corresponding to the fragmentation content acquisition request is simultaneously sent by the segmentation. During the startup phase, the server may use a uniform length for the fragment length, or adjust the fragment length interval during the startup phase: If the network condition is detected, the server side increases the score. Slice length; if the network condition is detected to be poor, the server side gradually reduces the fragment length. Optionally, the sending, by the sending, the fragmented content of the streaming media data corresponding to the fragmentation content obtaining request, is: increasing an upper limit threshold of a data sending bandwidth of the client in the startup phase, for example, twice as normal And the slice content of the streaming media data corresponding to the fragment content acquisition request is quickly pushed. Optionally, the sending the fragmented content of the streaming media data corresponding to the fragmentation content acquisition request may further include: sending the fragmented content of the streaming media data generated by using the non-uniform fragmentation mechanism.

The streaming media data sending method in the above startup phase provided by the embodiment of the present invention utilizes multiple transmissions Controlling the protocol TCP connection, sending the fragmented content of the streaming media data in the startup phase, achieving the technical effect of reducing the startup delay.

In order to effectively reduce the startup delay of the player when watching the network video, the user first analyzes each possible factor causing the delay, and then formulates the solution of the embodiment in a targeted manner, thereby reducing the startup delay. First, in order to reduce the delay of sending the description file, the embodiment of the present invention fully utilizes the content compression mechanism supported in the HTTP 1.1 protocol, and provides the compression capability of the entity in the HTTP response on the server, so that the server responds to the client. When requesting, you need to provide compressed (HTTP protocol supports gzip, deflate two compression formats), and add a Content-Encoding field in the entity header of the response message to identify the compression format used [RFC2616]. Because the Manifest files used in the existing Smooth Streaming scheme are in text format, the files in this format have a higher compression ratio, so the length of the compressed Manifest file is significantly reduced, so that the file can be significantly reduced. Delivery delay.

Secondly, in order to further reduce the startup delay, the embodiment of the present invention adopts a multi-TCP (Transmission Control Protocol) connection mechanism in the startup phase to quickly acquire the fragmentation content of the padding buffer, thereby achieving the purpose of fast startup. Specifically, after the player obtains and parses the Manifest, a URL (Uniform Resource Locator) that requests the content of the slice is generated. For example, for MS HTTP Streaming, it is http://host:port/[path/] Programjsm/QualityLevels(100000)/Fragments(video=1234 567890) , For Adobe HTTP Streaming, the shell lj is http:〃 host:port/[path/]programSegX-FragY. To obtain content fragments quickly using multiple TCP connections, you can use the Range-Request mechanism in HTTP 1.1, that is, the client uses the request header Range= _XXX -yyyy in the request message to indicate the byte range of the downloaded content. In order to first obtain the length of the content fragment to be requested, the client can obtain the length of the fragment to be requested through the HEAD (message header) method in HTTP 1.1. Taking MS Smooth Streaming as an example, as shown in FIG. 3, it is a schematic flowchart of a Smooth Streaming message interaction according to an embodiment of the present invention, which includes the following steps:

丄3D

丄3D OZ

OOZ ^: 3⁄43⁄4ϋ迹嚣

. (000 aVHH ^: ^ # 3⁄4

. ^

^im^-i^^ 'οακι ις/ ^+丄畓^ oi

^:丄^ M um Engraving ^3⁄4敏' ( ^s oi

Οακι w

'母进# i ^s i ^TO w3⁄4) } ^ 一雕' ₍ [Hj

6C66.0/0T0ZN3/X3d mOSl/llOZ OAV i. B = ^s order 'z>s 畓^ 's ^^m^- ^- ^iM m - ϋ$3⁄4^ΐ寒^^ 3⁄4申3⁄43⁄4^ z

3⁄4o ooz 丄3D 3⁄40 OOZ 丄3D dish doi

6C66.0/0T0ZN3/X3d Due to the diversity of the client, there may be cases where the client does not support the Range-Request mechanism in HTTP 1.1. In this case, the above mechanism may be modified to finally obtain content using multiple TCP connections. For example, the scope of the content to be requested can be identified by using an extended Query (query field) string in the URL of the HTTP request message. Taking Adobe Dynamic Streaming as an example, as shown in FIG. 4, it is a schematic flowchart of a Dynamic Streaming message interaction according to an embodiment of the present invention, which includes the following steps:

401-404, get *.swf file and compressed f4m file, client request:

GET http://host:port/[path/]program.f4m

Server response: 200 ok/r/nContent-Encoding: gzi .. Jr/n/r/n

405-410, judging whether it is currently in the startup stage? Yes, the fragmented content is obtained using multiple TCP connection segments:

According to the playable time of the received media content in the local receive buffer τ (initial value)

0), the lowest bit rate of the requested media content br (obtained in the f4m file), the estimated network transmission bandwidth w (the initial value is the f4m file length divided by the total time to obtain the f4m file), the duration of the previous slice t (obtained in the f4m file, the initial value is 0), the predetermined decision threshold THD0 (for example, 10s), to determine whether it is currently in the startup phase. The specific judgment algorithm is as follows:

If T+w*t/br<THD0, it is currently in the startup phase;

Otherwise, the startup phase ends.

In the startup phase, you can use the HEAD method of the HTTP protocol to get the length of the fragmented content. details as follows:

Client request: HEAD http://host:port/[path/]programSegX-FragY

The server side response: 200 OK\r\nContent-Length: 256001 \r\n\r\n

Then, the fragmentation content is obtained by using the Range-Request capability of the HTTP protocol. Customer p.

And request:

GET http://host:port/[path/]programSegX-FragY ? Range=0-

128000\r\iL..\r\n\r\n GET http://host:port/[path/]programSegX-FragY ? Range=128001- 256000\r\iL..\r\n\r\n

Server response:

200 OK\r\nContent-Length= 128001 \r\n ...\r\n\r\n

200 OK\r\nContent-Length= 128000\r\n ... \r\n\r\n

In this way, for the shard, the client and the server side establish two TCP connections at the same time, respectively, using an HTTP request segment to obtain the shard content, and after obtaining the responsive segment content respectively, the two segments are sequentially Splicing together to get the complete shard content.

411-414. After the startup phase, entering the normal phase, the multi-TCP connection is no longer used, but the fragmentation content is normally obtained, that is, the client requests the message:

GET http://host:port/[path/]programSegX-FragY

Server side response message:

200 OK

GET http://host:port/[path/]programSegX-FragY+l

200 OK In the normal phase, only one HTTP message is used each time to request the content of a slice, which does not increase the server's concurrency pressure.

Although the segment is divided into two segments in this example, the client can determine the segmentation in practice, as in the previous embodiment. In this case, the server side is required to recognize the Query field.

Similarly, if the client does not support the HEAD method in HTTP 1.1, the Query field can also be used to inform the server client that the length of the fragment needs to be obtained. Taking MS Smooth Streaming as an example, as shown in FIG. 5, it is a schematic flowchart of another message exchange of Smooth Streaming according to an embodiment of the present invention, which includes the following steps:

501-504, Get *.xap files and Manifest files. 3⁄40 OOZ

=O3p A)siu3iu§ j/(0009£†7 ;)spA3 ^r ;3⁄4HBni)/ms rasrixrejg(xid[ :iBd]/yod::isoi〃:(3⁄4:ii ςζ

丄 3D

Dish doi

, 9K-ns

U\ \U\ \- · -u\i\ooo Zl-0=^ ^ul3 il ^u3 l ^uo D ^u \ ^uo }^d 90Z

0000=° ³ Pi ^A ) ^s l ^u9m § ^m d/(000000 ^{s A9} l^in ^BN 0/ ^{ms mm} § ^OJ d[/qiBd]^od:isoq//:diiq

丄 3D

· " \0008Z: I -0=9§UB3⁄4U\J\(OOO 丄 3D 01

P^9H, (000

IH9 ^: This crack ^ 3⁄4

' m ^ ' am TTdM 3⁄4^^ ΐ3⁄4 with "s-sos

6C66.0/0l0JN3/X3<I mosi iioz OAV Http://host:port/[path/]programjsm sm/QualityLevels(64000)/Fragments(audio=10

In the normal phase, only one HTTP message is used each time to request the content of a slice, which does not increase the server's concurrency pressure.

Although the segment is divided into two segments in this example, the client can determine the segmentation in practice (same as the previous embodiment).

In order to further reduce the startup delay, the server side can quickly respond to the client's request during the startup phase of the video content. Because in practical applications, operators often set limits on the bandwidth on a single TCP connection in order to ensure that the server has high concurrency. At this time, you can make a little modification on the server. When the server receives the request from the client, it sees that the client requests to use the Range-Request or the Range-Request implemented by Query. When replying to the response message, you can increase the TCP. The maximum bandwidth of the connection speeds up the sending of response messages to further reduce the startup delay.

In some cases, the server side may not support the compression mechanism of the HTTP 1.1. In order to reduce the delay of sending the description file, this embodiment provides an implementation scheme of the segment delivery profile.

A file describing the manifest file (referred to as a secondary description file in this embodiment) is generated on the server side, and the content thereof is a length describing a common part, a Video part, and an Audio part of the manifest file;

When the user clicks on the video, for example, the player first requests the secondary description file as the client. If there is no such file, the original HTTP Streaming process is performed, and the complete manifest file is requested first, and the subsequent fragmented media files are requested one by one after parsing; Obtain the secondary description file, you can enable the quick start scheme, specifically: Parsing the secondary description file, obtaining the length of each part in the manifest file, for example, the public part 123, the video part 45678, the audio part 43210;

Using the HTTP partial request, first obtain the public part, 1/N of the video part, 1/N of the audio part, where N is a suitable integer, for example, when N=5, Range:bytes is used in the header field of the HTTP request. =0-122, 123-9159, 45801-54442, if the client or server does not support the header field, the method of the first embodiment can be used to implement the Range-Request by extending the URL of the request;

After obtaining the partial manifest, you can parse and start to request the fragmentation information of the audio and video. After the used mainfest is used, use the similar method to request the rest of the segment. In fact, you need to pay attention to the splicing of the two pieces before and after.

It should be noted that, in order to ensure that the first part of the manifest contains enough fragment index information, when the total length of the manifest is too small (for example, less than 10kB), the segmentation request manifest file is not required; during playback, the current part After the fragment index information in the manifest file is used, request to deliver the next 1/N part.

Secondly, in order to further reduce the startup delay, this embodiment adopts a multi-TCP connection mechanism to quickly acquire the fragment content of the padding buffer, thereby achieving the purpose of fast startup. The specific solution is similar to the foregoing embodiment, and details are not described in this embodiment.

Again, for some players, single frame playback is supported, so that the optimized start delay can be optimized by quickly displaying the first frame. Specifically, after the player receives the data of the first frame, the data of the first frame can be sent to the decoder for decoding and display, but in order to ensure the smoothness of subsequent playback, it is necessary to maintain a certain amount in the buffer. Data, therefore, can not receive a frame of data to display a frame of data, but after displaying the first frame of image, keep the first frame of image in the display window until the data in the buffer reaches the minimum playback threshold, and then continue playing Subsequent frames. In this way, with this scheme, the startup delay can be further reduced.

In particular, for some players, the buffer is counted in units of fragments rather than time, that is, the player starts to play the image after receiving N pieces of media content, instead of receiving M. The media content of the second starts to play after being sliced. At this time, the playback delay can be reduced by using non-uniform sharding. Specifically, when the media content is preprocessed on the server, a smaller fragment is used for the front part of the content, for example, the length of each fragment is Is in the previous part; and the normal fragment is used for the latter part of the content, for example, Part of each shard is 2s long. Further, a more complicated fragmentation scheme can be adopted. As shown in FIG. 6, it is a schematic diagram of the fragmented content of the streaming media data generated by the non-uniform fragmentation mechanism according to the embodiment of the present invention. With this fragmentation mechanism, the playback delay can be effectively reduced.

The above embodiment of the present invention first analyzes the factors causing the HTTP Streaming startup delay, and then proposes corresponding solutions for each factor, thereby achieving the goal of reducing the startup delay.

As shown in FIG. 7, a schematic structural diagram of a client device for acquiring streaming media data in a startup phase according to an embodiment of the present invention, where the client device includes:

The obtaining unit 71 is configured to acquire a streaming media content description file.

The request generating unit 72 is configured to send, according to the streaming media content description file, a generated fragment content obtaining request to the server;

The obtaining unit 71 is further configured to: use the multiple transmission control protocol TCP connection in the startup phase, and obtain, from the server end, the fragment of the streaming media data corresponding to the fragmentation content acquisition request, the client The terminal device may further include: a startup phase determining unit 74, configured to determine that the client is currently in a startup phase before transmitting the slice content acquisition request. The startup phase determining unit 74 is specifically configured to: according to the playable time of the received media content in the local receiving buffer, the lowest code rate of the requested media content, the estimated network transmission bandwidth, the duration of the previous fragment, and the predetermined The decision threshold determines whether the client is currently in the startup phase. The obtaining unit 71 is specifically configured to obtain the streaming media content description file compressed by the Hypertext Transfer Protocol (HTTP) protocol, or obtain the streaming media content description file in segments.

Optionally, the obtaining unit 71 is specifically configured to use a streaming media content description file to obtain a location Defragment length of the streaming media data in the startup phase, or obtaining the fragmentation length of the streaming media data in the startup phase by using a message header method in HTTP 1.1, or acquiring the extended query field in the URL of the HTTP request message Defragment length of the streaming media data in the startup phase; according to the fragment length, after the TCP connection is established with the server end by using a concurrent hypertext transfer protocol HTTP message, using the multiple The transmission control protocol TCP connection acquires the fragmented content of the streaming media data corresponding to the fragment content acquisition request.

During the startup phase, the fragment length obtained by the obtaining unit 71 adopts a uniform length, or adjusts the fragment length interval one by one during the startup phase: if the network condition is detected to be excellent, the server end The fragment length is increased step by step; if the network condition is detected to be poor, the server side gradually reduces the fragment length.

Optionally, the client device may further include: a display unit 73, configured to parse the slice content of the streaming media data in the startup phase, present a first frame video image, and then keep displaying in the play window until the buffer The data meets the requirements for subsequent smooth playback.

The client device provided by the embodiment of the present invention obtains the fragmentation content of the streaming media data in the startup phase by using multiple transmission control protocol TCP connections, and achieves the technical effect of reducing the startup delay.

FIG. 8 is a schematic structural diagram of a server device for transmitting streaming media data in a startup phase according to an embodiment of the present invention, where the server device includes:

a sending unit 81, configured to send a streaming media content description file;

The request receiving unit 82 is configured to receive a fragmentation content acquisition request sent by the client according to the streaming media content description file;

The sending unit 81 is further configured to send, by using a plurality of transmission control protocol TCP connections in the startup phase, the fragmented content of the streaming media data corresponding to the fragmentation content acquisition request.

Optionally, the sending unit 81 is specifically configured to send the streaming media content description file compressed by the Hypertext Transfer Protocol (HTTP) protocol, or send the streaming media content description file in segments. Optionally, the sending unit 81 is specifically configured to: before sending the content corresponding to the fragment content obtaining request, determining that the client is currently in a startup phase; in the startup phase, using a concurrent hypertext transfer protocol After the TCP connection is established with the client, the plurality of transmission control protocol TCP connections are used, and the fragmentation of the streaming media data corresponding to the fragmentation content acquisition request is simultaneously sent by using the plurality of transmission control protocol TCP connections. content.

Optionally, during the startup phase, the length of the fragment sent by the sending unit 81 is a uniform length, or the fragment length interval is adjusted one by one during the startup phase: if the network condition is detected, The server side increases the fragment length gradually; if the network condition is detected to be poor, the server side gradually reduces the fragment length.

Optionally, the sending unit 81 is configured to: in the startup phase, increase an upper threshold of a data sending bandwidth of the client to quickly push the fragmented content of the streaming media data corresponding to the fragmented content obtaining request.

Optionally, the sending unit 81 is specifically configured to send the fragmented content of the streaming media data generated by the non-uniform fragmentation mechanism.

Optionally, the sending unit 81 is further configured to determine, according to whether the request message from the client includes a Range-Request header field or an extended Range-Request request field, whether the client is currently in a startup phase.

The server device in the embodiment of the present invention may be a physical media server, or may be a network, such as a CDN (Content Delivery Network) network.

The server device provided by the embodiment of the present invention uses a plurality of transmission control protocol TCP connections to transmit the fragmented content of the streaming media data in the startup phase, thereby achieving the technical effect of reducing the startup delay.

A person skilled in the art can understand that all or part of the steps of implementing the above embodiments can be completed by a program instructing related hardware, and the program can be stored in a computer readable storage medium, and the program is executed. Including all or part of the above, the storage medium, such as: ROM/RAM, magnetic disk, optical disk, and the like. The specific embodiments of the present invention have been described in detail with reference to the preferred embodiments of the present invention. The scope of the invention, any modifications, equivalents, improvements, etc., made within the spirit and scope of the invention are intended to be included within the scope of the invention.

Claims

Claim

A method for acquiring streaming media data in a startup phase, the method comprising:

Obtain a streaming media content description file;

Generating a fragmented content acquisition request to the server according to the streaming media content description file

3⁄4 ;

The fragmentation content of the streaming media data corresponding to the fragmentation content acquisition request is obtained from the server end by using a plurality of transmission control protocol TCP connections in the startup phase.

2. The method of claim 1, wherein the method further comprises:

Before sending the fragment content acquisition request, it is determined that it is currently in the startup phase.

The method of claim 1, wherein the obtaining the streaming media content description file comprises:

Obtaining the streaming media content description file compressed by the Hypertext Transfer Protocol HTTP protocol, or acquiring the streaming media content description file in segments.

The method according to claim 1, wherein the fragmentation content of the streaming media data corresponding to the fragment content acquisition request is obtained from the server end by using a plurality of transmission control protocol TCP connections in the startup phase. , including:

Obtaining, by using the streaming media content description file, the fragmentation length of the streaming media data in the startup phase, or obtaining the fragmentation length of the streaming media data in the startup phase by using a message header method in HTTP1.1, or by using HTTP The extended query field in the URL of the request message acquires the slice length of the streaming media data in the startup phase;

And establishing, according to the length of the fragment, a plurality of transmission control protocol TCP connections with the server end by using a concurrent hypertext transfer protocol HTTP message;

The fragmentation content of the streaming media data corresponding to the fragmentation content acquisition request is acquired by using the plurality of transmission control protocol TCP connections.

5. The method of claim 4 wherein: During the start-up phase, the slice length adopts a uniform length, or the slice length interval is adjusted one by one during the start-up phase: if the network condition is detected to be excellent, the server end increases the slice length gradually; If it is detected that the network condition is poor, the server side gradually reduces the slice length.

The method of claim 1, wherein after the acquiring the fragmented content of the streaming media data corresponding to the fragmented content acquisition request, the method further includes:

Parsing the fragmented content of the streaming media data, presenting the first frame of the video image, and then maintaining the display in the playback window until the buffer data meets the requirements for subsequent smooth playback.

7. A method for transmitting streaming media data in a startup phase, the method comprising:

Send a streaming media content description file;

Receiving a fragment content acquisition request sent by the client according to the streaming media content description file; and using the multiple transmission control protocol TCP connection in the startup phase, sending the fragmented content of the fragmented content acquisition request corresponding to the streaming media data.

The method of claim 7, wherein the sending the streaming media content description file comprises:

Sending the streaming media content description file compressed by the Hypertext Transfer Protocol HTTP protocol, or sending the streaming media content description file in segments.

The method according to claim 7, wherein the fragmentation content of the streaming media data corresponding to the fragmentation content acquisition request is sent by using a plurality of transmission control protocol TCP connections in the startup phase, including:

Determining that the client is currently in a startup phase before transmitting the content corresponding to the fragment content acquisition request;

In the startup phase, establishing, by the client, the plurality of transmission control protocol TCP connections by using a concurrent hypertext transfer protocol HTTP message;

Simultaneously transmitting the fragmented content acquisition by using the plurality of transmission control protocol TCP connections Request the fragmented content of the corresponding streaming media data.

10. The method of claim 9 wherein:

During the start-up phase, the slice length adopts a uniform length, or the slice length interval is adjusted one by one during the start-up phase: if the network condition is detected to be excellent, the server side increases the slice length by itself; If the network status is poor, the server side will gradually reduce the fragment length.

The method according to claim 7, wherein the sending the fragmented content of the streaming media data corresponding to the fragmentation content acquisition request comprises:

The upper threshold of the data transmission bandwidth of the client is increased in the startup phase to quickly push the fragmented content of the streaming media data corresponding to the fragmentation content acquisition request.

And sending the fragmented content of the streaming media data corresponding to the fragment content acquisition request generated by the non-uniform fragmentation mechanism.

13. A client device for obtaining streaming media data in a startup phase, wherein the client device comprises:

An obtaining unit, configured to acquire a streaming media content description file;

a request generating unit, configured to send a fragmentation content acquisition request to the server according to the streaming media content description file;

The obtaining unit is further configured to acquire, by using a plurality of transmission control protocol TCP connections in the startup phase, the fragment content of the streaming media data corresponding to the fragment content acquisition request from the server end.

The client device according to claim 13, wherein the client device further comprises:

The startup phase determining unit is configured to determine that the client is currently in a startup phase before sending the fragment content acquisition request.

The client device according to claim 13, wherein the acquiring unit is specifically configured to acquire the streaming media content description text compressed by the Hypertext Transfer Protocol (HTTP) protocol. Or the segmentation of the streaming media content description file.

The client device according to claim 13, wherein the acquiring unit is configured to acquire a fragment length of the streaming media data in the startup phase by using a streaming media content description file, or by using HTTP 1.1. Obtaining a fragment length of the streaming media data in the startup phase, or obtaining a fragment length of the streaming media data in the startup phase by using an extended query field in a URL of the HTTP request message; Length, by using a concurrent Hypertext Transfer Protocol (HTTP) message, after establishing a plurality of transmission control protocol TCP connections with the server end, using the plurality of transmission control protocol TCP connections, and simultaneously acquiring the fragment content acquisition request by segmentation The fragmented content of the corresponding streaming media data.

And a display unit, configured to parse the slice content of the streaming media data in the startup phase, present the first frame video image, and then keep displaying in the play window until the buffer data satisfies the requirement of subsequent smooth play.

18. A server device for transmitting streaming media data in a startup phase, wherein the server device comprises:

a sending unit, configured to send a streaming media content description file;

a request receiving unit, configured to receive a fragment content acquisition request sent by the client according to the streaming media content description file;

The sending unit is further configured to send, by using a plurality of transmission control protocol TCP connections in the startup phase, the fragmented content of the streaming media data corresponding to the fragmentation content acquisition request.

The server device according to claim 18, wherein the sending unit is specifically configured to send the streaming media content description file compressed by a hypertext transfer protocol HTTP protocol, or send the streaming media in segments. Content description file.

The server device according to claim 18, wherein the sending unit is specifically configured to: before transmitting the content corresponding to the fragment content obtaining request, determining that the client is currently located a startup phase, in the startup phase, after the TCP connection of the plurality of transmission control protocols is established by the client by using a concurrent hypertext transfer protocol HTTP message, using the multiple transmission control protocol TCP connection, segmentation simultaneously And sending the fragment content of the streaming media data corresponding to the fragment content acquisition request.

21. The server apparatus according to claim 20, wherein:

During the startup phase, the fragment length sent by the sending unit adopts a uniform length, or the fragment length interval is adjusted one by one during the startup phase: if the network condition is detected, the server end is increased. Large slice length; if the network condition is detected to be poor, the server side gradually reduces the slice length.

The server device according to claim 18, wherein the sending unit is configured to: increase an upper threshold of a data transmission bandwidth of the client in the startup phase to quickly push the fragment content acquisition request The fragmented content of the corresponding streaming media data.

The server device according to claim 18, wherein the sending unit is configured to send, in a fragment of the streaming media data of the startup phase generated by using a non-uniform fragmentation mechanism.