KR100677125B1 - Streaming method using negotiation of sending delay time - Google Patents

Abstract

A streaming method using negotiation of transmission delay time is disclosed. The present invention provides a streaming method for transmitting a stream including one or more frames from a server to a client, the method comprising: a) receiving, from a client, a proposal value of a maximum transmission delay time determined based on a maximum pre-buffering time of the reception buffer of the client. Doing; b) determining, as the maximum transmission delay time, any value smaller than the suggested value of the maximum transmission delay time; And c) transmitting the stream to the client while outputting only a frame having a transmission delay time smaller than the maximum transmission delay time from the transmission buffer to the transmission line. The present invention relates to a streaming method that prevents cliché data from occurring by negotiating a transmission delay time and / or transmission lead time between a server and a client.

Description

Streaming method using negotiation of sending delay time

1 is a diagram showing a streaming state when the transmission buffer is too large.

2 is a diagram illustrating a streaming state when the transmission buffer is too small.

3 is a time flow diagram illustrating a streaming method according to a first embodiment of the present invention.

4 is a time flow diagram illustrating a streaming method according to a second embodiment of the present invention.

5 is a time flow diagram illustrating a streaming method according to a third embodiment of the present invention.

6 is a time flow diagram illustrating a streaming method according to a fourth embodiment of the present invention.

7 is a diagram illustrating a concept of maximum transmission lead time.

8 is a time flow diagram illustrating a streaming method according to a fifth embodiment of the present invention.

9 is a time flow diagram illustrating a streaming method according to a sixth embodiment of the present invention.

TECHNICAL FIELD The present invention relates to a streaming method, and more particularly, to prevent clichés from occurring by negotiating a transmission delay time and / or transmission lead time with a server and a client, and to prevent a transmission speed of another client from being reduced. It is about a method.

Real-time playback is being implemented in various applications such as digital broadcasting, VOD, and AOD.

In real time playback, a transmission system of an audio or video stream is composed of a streaming server (hereinafter referred to as a server) for transmitting the stream and a streaming client (hereinafter referred to as a client) for receiving, decoding and playing the transmitted stream.

Servers are divided into two types. One is a broadcast type server which stores contents received through broadcasting in a transmission buffer and transmits the contents to a client. The other is a file type server which stores the contents as a file and converts the contents into a stream and transmits the contents to the client. The former case further includes a tuner for tuning the broadcast stream and a buffer for temporarily storing the tuned stream. Both types of servers must determine how delayed the stream stored on the server side is to the client. In the broadcast server, the aforementioned 'how long' is determined by the size of the transmission buffer.

On the other hand, the client includes a reception buffer for temporarily storing the stream transmitted from the server, and a playback unit for decoding and playing the stream stored in the reception buffer.

In real time playback, how much delayed streaming is transmitted from the server side has a great influence on whether the data played by the client is real time and the quality of the stream.

1 to 2 are diagrams showing a streaming situation by a conventional streaming method.

1 is a diagram illustrating a streaming state when the transmission buffer is too large.

1, the transmission system comprises a server 10, a client 20 and a transmission line 30, the server 10 includes a tuner 12 and a transmission buffer 14, the client 20 receives A buffer 22 and a playback section 24; The transmission line 30 uses various transmission protocols such as TCP and UDP. The reception buffer 22 functions to provide streaming data, which is input at an inconsistent rate, to the playback unit at a constant rate.

In FIG. 1, due to congestion on the temporary transmission line 30, the transmission buffer 14 and the transmission line 30 contain up-to-date data and out of date or staled data. Coexist. Up-to-date data refers to data that is useful at a particular playback time of the client, and out-of-date data refers to data that is useless at a particular playback time of the client. That is, in FIG. 1, since the current client must play streaming in real time, if the data D1 is not included in the reception buffer 22 at the time point t1, the playback unit 24 cannot reproduce the data D1 at the time point t1 and the time t1. You must pass by. This means that at a point in time after time t1, the data D1 is no longer up-to-date data but is obsolete data from the client's point of view.

In Fig. 1, since the size of the transmission buffer 14 is large, i.e., the streaming transmission delay time on the server 10 side is too large, a problem arises that cliché data occurs in streaming.

2 is a diagram illustrating a streaming state when the transmission buffer is too small.

2 shows a case where the size of the transmission buffer is minimized as much as possible. Therefore, unlike FIG. 1, when data is transmitted and a collision occurs on a transmission line, streaming data transmission delay time is not generated. However, when the server is a broadcast server, since the size of the transmission buffer 14 is small, some of the data transmitted from the tuner 12 to the server-side buffer 14 cannot be stored in the buffer and are lost. .

Accordingly, the present invention has been made to solve the above-described problem, and in streaming for real-time playback, a server and a client negotiate a transmission delay time to provide a streaming method that prevents the generation of obsolete data and data loss.

The present invention for solving the above problems, in the streaming method for transmitting a stream containing one or more frames from the server to the client, a) the maximum transmission determined from the client based on the maximum pre-buffering time of the receiving buffer of the client Receiving a suggested value of a delay time; b) determining, as the maximum transmission delay time, any value smaller than the suggested value of the maximum transmission delay time; And c) transmitting the stream to the client while outputting only a frame having a transmission delay time smaller than the maximum transmission delay time from the transmission buffer to the transmission line.

In another aspect, the present invention provides a streaming method for transmitting a stream including one or more frames from a server to a client, the method comprising the steps of: a) receiving a proposal value of a maximum transmission lead time determined from a client based on a real-time playback streaming rate of the client; ; b) determining a maximum transmission lead time based on the suggested value of the maximum transmission lead time; And c) transmitting the stream to the client while outputting only a frame having a transmission leading time smaller than the maximum transmission leading time from the transmission buffer to the transmission line.

In addition, the present invention provides a streaming method for transmitting a stream including one or more frames from a server to a client, the method comprising the steps of: a) receiving a proposal value of a maximum transmission rate determined from a client based on a real-time playback streaming rate of the client; b) determining a maximum transmission rate, which is the maximum rate streamable to the client, based on the network load on other clients connected to the server; And c) if the maximum transmission rate is equal to or greater than the suggested value of the maximum transmission rate, transmitting the stream to the client according to the suggested value of the maximum transmission rate.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

3 is a time flow diagram illustrating a streaming method according to a first embodiment of the present invention.

In step 310, the client sends the proposed value Td_max_requst of the maximum transmission delay time to the server. The suggested value of the maximum transmission delay time can be appended in the header of the application layer protocol. For example, if the application layer protocol is HTTP, it can be attached in an HTTP GET command. The suggested value of the maximum transmission delay time is determined to be any value within the maximum pre-buffering time that the client can configure in hardware.

In step 320, the server determines, as the maximum transmission delay time Td_max, any value smaller than the suggested value Td_max_request of the maximum transmission delay time sent from the client. The meaning of the maximum transmission delay time is described below.

The maximum transmission delay time is a threshold at which the server drops some of the data contained in the transmission buffer when the obsolete data is generated due to congestion of the transmission line. That is, the server deletes all frames having a transmission delay time larger than the maximum transmission delay time Td_max in the transmission buffer and does not transmit them to the client. The transmission delay time is defined as follows.

[Equation 1]

Here, Td (i) denotes a transmission delay time of an I-th frame, T _actual (i) denotes an actual transmission time of an I-th frame, and T _realtime (i) denotes a transmission time of an I-th frame that satisfies a real-time reproduction condition. The transmission time T _realtime (i) of the I-th frame that satisfies the real time reproduction condition is expressed by Equation 2 below.

[Equation 2]

Where T0 is the streaming start time, that is, the transmission time of the first frame transmitted by the server, Tst (1) is the timestamp of the first frame, and Tst (i) is the timestamp of the Ith frame.

According to equations (1) and (2), a frame with Td> Td_max is determined as out-of-date data. That is, a frame having Td> Td_max is determined as data to be deleted from the transmission buffer.

In step 330, the server sends the maximum transmission delay time Td_max to the client. The maximum transmission delay time Td_max can be appended in the header of the protocol of the application layer. For example, if the application layer protocol is HTTP, it can be attached in the header of an HTTP OK command.

In step 340, the client determines the maximum transmission delay time Td_max received in step 330 as a minimum reception pre-buffering time (T_buffer). The minimum reception buffering time is a minimum value of the client's buffering time, and has a relationship between the size of the reception buffer and the following equation (3).

[Equation 3]

Where Buffersize_client is the size of the receive buffer, Td_max is the maximum transmission delay time, and BitRate is the bit rate of the stream.

In step 350, the server sends the stream to the client according to the maximum transmission delay time Td_max determined in step 320. In other words, the server calculates a transmission delay time Td (i) for each frame according to Equation 1, and deletes a frame in which the calculated transmission delay time Td (i) is larger than the maximum transmission delay time Td_max from the transmission buffer. Send the stream to the client.

In step 360, the client receives the stream according to the minimum receive buffering time or the size of the minimum receive buffer determined in step 340. In other words, the client receives the stream from the server while deleting a frame present in the received frame beyond the minimum receive buffering time from the received frame.

In the field of real-time transmission, commonly used protocol stacks are TCP / UDP (Transport Layer) and HTTP / RTP (Application Layer). In particular, since TCP does not provide QoS, negotiation of the maximum transmission delay time and the minimum reception buffering time described above is important.

4 is a time flow diagram illustrating a streaming method according to a second embodiment of the present invention.

Even in real time transmission, it may be necessary to store every frame of a stream transmitted from a server in a storage medium in a client. In general, this is the case when the content delivery to the client serves not only real time playback but also a simple download purpose. 4 has an advantageous configuration in this case.

In step 410, the client sends a delay flag Flag and a suggested value Td_max_requst of the maximum transmission delay time to the server. Delay flag Flag is a flag indicating that the suggested value of the maximum transmission delay time is either infinity or a finite value. For example, by setting the delay flag to 0, it may represent that the suggested value of the maximum transmission delay time is infinite. When the proposal value of the maximum transmission delay time is infinite, an embodiment in which the proposal value of the maximum transmission delay time is not transmitted to the server is possible. The delay flag can also be attached in the header of the application layer protocol.

In step 420, the server proceeds to step 425 if the delay flag sent in step 410 indicates that the suggested value of the maximum transmission delay time is infinity, otherwise proceeds to step 430.

In step 425, the server sends all frames to the client upon transmission of the stream. In other words, even if a delay occurs in the transmission line and obsolete data is generated, the server does not determine which part of the data in the transmission buffer is the obsolete data. This is because the maximum transmission delay time is infinite.

In step 430, the server determines the maximum transmission delay time Td_max to any value smaller than the suggested value Td_max_request of the maximum transmission delay time.

In step 440, the server sends the maximum transmission delay time Td_max to the client.

In step 450, the client determines the maximum transmission delay time Td_max received in step 440 as the minimum reception buffering time (T_buffer).

In step 460, the server sends the stream to the client according to the maximum transmission delay time Td_max determined in step 430.

In step 470, the client receives the stream according to the minimum receive buffering time or the size of the minimum receive buffer determined in step 450.

According to the embodiment of FIG. 4, the client may request the server to transmit all the frames to the server by sending a delay flag indicating that the proposed maximum transmission delay time is infinite. As a result, the client cannot reproduce full image quality or sound quality during the real time reproduction, but can reproduce the full image quality or sound quality in future playback. This is because all frames of the stream are stored in the playback medium of the client.

5 is a time flow diagram illustrating a streaming method according to a third embodiment of the present invention.

Some application layer protocols support packet retransmission. For example, the TCP / HTTP combination does not perform retransmission of packets at the HTTP level because it guarantees the completion of packets at the TCP layer. However, in the case of the UDP / RTP combination, since UDP does not guarantee the transmission of a completed packet, RTP transmits a packet by performing a so-called packet retransmission that retransmits the packet when there is no response for a certain time after the packet transmission. To ensure. 5 provides a streaming method for determining the number of retransmissions in case of such packet retransmission.

In step 510, the client sends the proposed value Td_max_requst of the maximum transmission delay time to the server. The suggested value of the maximum transmission delay time is determined to be any value within the maximum pre-buffering time that the client can configure in hardware.

In step 520, the server determines, as the maximum transmission delay time Td_max, any value smaller than the suggested value Td_max_request of the maximum transmission delay time sent from the client.

In step 530, the server determines the maximum number of retransmissions. The maximum number of retransmissions is determined using Equation 4 below.

[Equation 4]

Where Nmax is the maximum number of retransmissions, and Trt is the round trip time for one retransmission, that is, the time it takes for one IP packet to be sent from the server to the client and then back from the client to the server. Equation 4 states that since the packet transmitted after the maximum transmission delay time is no longer the latest data, the total retransmission time (number of retransmissions * count trip time) cannot be greater than the maximum transmission delay time. Is derived based on the concept.

In step 540, the server sends the maximum transmission delay time Td_max to the client.

In step 550, the client determines the maximum transmission delay time Td_max received in step 540 as the minimum reception buffering time (T_buffer).

In step 560, the server sends the stream to the client according to the maximum transmission delay time Td_max determined in step 520 and the maximum number of retransmissions N determined in step 530.

In step 570, the client receives the stream according to the minimum receive buffering time determined in step 550.

6 is a time flow diagram illustrating a streaming method according to a fourth embodiment of the present invention.

One or more frames of the stream to be transmitted, one frame containing one or more packets. Therefore, the loss of a packet may not necessarily be regarded as a loss of a frame. This is because even if the packet is not retransmitted, the error correction algorithm provided by the transport protocol can be used to guarantee the complete packet. The embodiment of FIG. 6 provides a streaming method for performing retransmission only when necessary.

In step 610, the client sends the proposed value Td_max_requst of the maximum transmission delay time to the server. The suggested value of the maximum transmission delay time is determined as an arbitrary value within the maximum pre-buffering time that the client can configure in hardware.

In step 620, the server determines, as the maximum transmission delay time Td_max, any value smaller than the suggested value Td_max_request of the maximum transmission delay time sent from the client.

In step 630, the server determines the probability of frame loss. The frame loss probability is determined using Equation 5 below.

[Equation 5]

Where Pfrm is the frame loss probability, Ppkt is the packet loss probability, and N is the number of packets included in the frame. The packet loss probability Ppkt is determined by using Equation 6 below.

[Equation 6]

Where Ppkt is the probability of packet loss, P0 is the probability that the UDP packet will be lost when UDP packets are sent from server to client or from client to server (1-number of total packets received / number of total packets transmitted), M Is determined using Equation 7 below as the number of times a packet is transmitted as it is routed from server to client or from client to server before the frame is considered out of date data.

[Equation 7]

Where Nmax is the maximum number of retransmissions, and Trt means the round trip time for one retransmission, that is, the time from the first transmission of a packet to the next transmission.

In step 640, the server sends the maximum transmission delay time Td_max to the client.

In step 650, the server determines whether the frame loss probability calculated in step 630 exceeds a predetermined threshold. If it exceeds, proceed to steps 660 to 680, otherwise proceed to step 655.

In step 660, the server determines the maximum number of retransmissions according to equation (4).

In step 670, the client determines the maximum transmission delay time Td_max received in step 640 as the minimum reception pre-buffering time.

In step 680, the server sends the stream to the client according to the maximum transmission delay time Td_max determined in step 620 and the maximum number of retransmissions Nmax determined in step 660.

In step 655, the stream is sent to the client according to the maximum transmission delay time determined in step 620. At this time, retransmission is not performed.

In step 690, the client receives the stream according to the minimum receive buffering time determined in step 670. In this case, since the packet retransmission is not performed, the client recovers a packet lost by jitter or the like by using an error correction algorithm such as forward error correction.

7 is a diagram for explaining a concept of maximum transmission lead time.

3 to 6 is a streaming method in which the server and the client negotiate the maximum transmission delay time to prevent the generation of obsolete data. Similarly to the maximum transmission delay time, a streaming method for negotiating the maximum sending advance time Ta_max may also be proposed.

In FIG. 7, the current server 700 transmits streaming to the first client 710 and the second client 720 through a transmission line 702 having a bandwidth of 20 Mbps. At this time, the transmission line 702 is divided into a first transmission line 712 to the first client and a second transmission line 722 to the second client, and if there is no special priority for transmission bandwidth, each transmission line is equally divided into 20 / A bandwidth of 2 = 10 Mbps is allocated. In such a situation, suppose that the first client 710 is going to play an audio streaming of 256kbps / 256MB, and the second client 720 is going to play an HD video streaming of 19Mbps / 19GB.

On the other hand, similar to the transmission delay time (Equation 1), the transmission leading time is defined as in Equation 8 below.

[Equation 8]

Here, Ta (i) is the transmission lead time of the I-th frame, T _actual (i) is the actual transmission time of the I-frame, and T _realtime (i) is the transmission time of the I-frame that satisfies the real-time reproduction condition.

In the situation of FIG. 7, if there is no negotiation of transmission lead time, the first client may receive 256kbps / 256MB of audio streaming at 10Mbps, and the second client may receive 19Mbps / 19GB of video streaming at 10Mbps. will be. Therefore, during the time 256MB / 10Mbps = 256 * 8/10 = 204.8sec when the first client receives 256MB of audio streaming, the second client has 19Mbps, which is the bandwidth of video streaming, than the maximum bandwidth 10Mbps that can be allocated to the second transmission line. Because of the larger size, loss of frames occurs, resulting in degradation of image quality.

One way to prevent this is to limit the transfer rate to the first client only to the extent that the first client is capable of real time playback. The method of limiting the transmission rate is to check the transmission lead time for each frame, and if the transmission lead time is larger than the maximum transmission lead time, wait until the transmission lead time is smaller than the maximum transmission lead time after waiting without transmitting. Will be sent. However, this method is not preferable because the client cannot perform the client-based fast-forward trick mode.

Therefore, it is necessary to negotiate the transmission lead time to satisfy the request for the transmission speed of the first client and to prevent deterioration of the image quality of the second client.

8 is a time flow diagram illustrating a streaming method according to a fifth embodiment of the present invention.

In step 810, the client sends the suggested value Ta_max_requst of the maximum transmission leading time to the server. The suggested value of the maximum transmission lead time may be appended in the header of the application layer protocol. For example, if the application layer protocol is HTTP, it can be attached in an HTTP GET command.

In step 820, the server determines the maximum transmission lead time Ta_max, taking into account the network load to other clients connected to the server, from any value less than the suggested value Ta_max_request of the maximum transmission lead time sent from the client.

When the first client requests a new streaming from the server or demands more bandwidth for an existing streaming rate (for fast forward trick mode), the specific method of determining the maximum transmission leading time is as follows.

First, the total real time playback condition bandwidth (BW_rt) satisfying the real time playback conditions of all other clients (second, third, ... clients) currently connected to the server is calculated. The total real time playback condition bandwidth is the sum of the real time playback rates of each streaming.

Next, the available bandwidth (BW_avail) is calculated by subtracting the total real-time playback condition bandwidth (Realtime Bandwith) from the total bandwidth (BW_ch) of the transmission line.

Then, based on the free bandwidth and the streaming rate requested by the first client, an allowable transmission lead time Ta_allow, which is an allowable transmission lead time for the first client, is calculated for each frame.

Finally, the maximum transmit lead time (Ta_max) allowed for the first client is determined by selecting any value among the values smaller than the allowable transmit lead time.

Therefore, a frame having a transmission lead time smaller than the maximum transmission lead time is transmitted from the transmission buffer to the transmission line only when the transmission lead time becomes less than or equal to the maximum transmission lead time.

In step 830, the server sends the maximum transmission leading time Ta_max to the client. The maximum transmission lead time Ta_max may also be appended in the header of the protocol of the application layer. For example, if the application layer protocol is HTTP, it can be attached in the header of an HTTP OK command.

In step 840, the client determines the maximum transmission leading time Ta_max received in step 830 as the minimum reception pre-buffering time (T_buffer). The minimum receive buffering time is the minimum of the client's buffering time. This is because the client must be able to store more data in the receive buffer than the minimum maximum send lead time.

In step 850, the server sends the stream to the client according to the maximum transmit leading time Ta_max determined in step 820. In other words, the server calculates the transmission leading time Ta (i) for each frame according to Equation 8, and outputs only the frames whose transmission leading time Ta (i) is smaller than the maximum transmission leading time Ta_max from the transmission buffer to the transmission line. While sending the stream.

In step 860, the client receives the stream according to the minimum receive buffering time determined in step 840.

9 is a time flow diagram illustrating a streaming method according to a sixth embodiment of the present invention.

Unlike the embodiment of FIG. 8, the embodiment of FIG. 9 illustrates a streaming method using the concept of the maximum transmission rate instead of the maximum transmission lead time. This case is a streaming method for a case where a client already connected and playing streaming wants to perform a fast forward trick mode.

In step 910, the client transmits a proposal value S_max_requst of the maximum transmission rate to the server. For example, a client can request a server-side 6X client-based fast forward trick mode. Unlike server-based fast forward, the performance of the client-based fast forward trick mode must double the transmission speed from the server to the client. The suggested value of the maximum transmission rate can be appended in the header of the application layer protocol. For example, if the application layer protocol is HTTP, it can be attached in an HTTP GET command.

In step 920, the maximum transmission rate S_max is determined in consideration of the network load on other clients connected to the server.

A specific method of determining the maximum transmission rate is as follows.

First, the total real time playback condition bandwidth (BW_rt) satisfying the real time playback conditions of all other clients (second, third, ... clients) currently connected to the server is calculated. The total bandwidth is the sum of the real time playback rates of each streaming.

Next, the available bandwidth (BW_avail) is calculated by subtracting the total real-time playback condition bandwidth (Realtime Bandwith) from the total bandwidth (BW_ch) of the transmission line. The extra bandwidth is the maximum transmission rate S_max.

In step 930, the server checks whether the maximum transmission rate S_max is greater than or equal to the suggested value S_max_request of the maximum transmission rate. If greater than or equal to proceed to step 940 otherwise proceed to step 950.

In step 940, the server sends streaming to the client at the suggested value of the maximum transmission rate.

In step 950, the server sends a non-sendable message to the client indicating that it cannot stream at the suggested value of the maximum transmission rate requested by the client.

In the above embodiment, it is also possible to indicate the transmission speed by using the magnification. Magnification is the ratio of the actual transmission speed to the playback speed that meets real-time playback conditions. For example, if the playback speed that meets real-time playback conditions is 3Mbps and the transmission rate multiplier is 2x, then the actual transmission speed is 3 * 2 = 6Mbps.

Meanwhile, the streaming method according to the present invention can be written in a computer program. Codes and code segments constituting the program can be easily inferred by a computer programmer in the art. The program is also stored in a computer readable media, which is read and executed by a computer to implement a streaming method. The information storage medium includes a magnetic recording medium, an optical recording medium, and a carrier wave medium.

So far I looked at the center of the preferred embodiment for the present invention. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

As described above, according to the present invention, in a streaming for real time playback, a streaming method is provided in which a server and a client negotiate a transmission delay time to prevent the generation of obsolete data and data loss.

In addition, according to the present invention, there is provided a streaming method that prevents the slowing down of streaming of another client by negotiating transmission lead time or transmission speed.

Claims (27)

In the streaming method for transmitting a stream containing one or more frames from the streaming server to the streaming client, a) receiving from the client a suggested value of the maximum transmission delay time determined based on the maximum pre-buffering time of the client's receive buffer; b) determining, as the maximum transmission delay time, any value smaller than the suggested value of the maximum transmission delay time; And c) transmitting, by the server, the stream to the client while selectively outputting only frames having a transmission delay time less than the maximum transmission delay time from the transmission buffer to the transmission line for real time reproduction of the stream. How to. 2. The method of claim 1, wherein step c) includes deleting a frame in the transmission buffer that has a transmission delay time greater than the maximum transmission delay time. 2. The method of claim 1, wherein the suggested value of the maximum transmission delay time is included in a header of an application protocol. The method of claim 1, wherein the transmission delay time is

Where Td (i) is the transmission delay time of the I-th frame, T _actual (i) is the actual transmission time of the I-frame, and T _realtime (i) is the I-frame of the real time playback condition. Means a transmission time. The transmission time T _realtime (i) of the I-th frame that satisfies the real-time reproduction condition is expressed by the following equation.

And T0 is the streaming start time, that is, the transmission time of the first frame transmitted by the server, Tst (1) is the timestamp of the first frame, and Tst (i) is the timestamp of the Ith frame. Characterized in that the method. 4. The method of claim 3, wherein the application protocol comprises one of HTTP and RTP. 2. The method of claim 1, further comprising d) receiving the stream by a client, wherein the minimum receive buffering time of the client is equal to or greater than the maximum transmission delay time. 8. The method of claim 7, wherein the maximum transmission delay time is included in a header of an application protocol and transmitted from the server to the client. The method of claim 1, wherein step a) comprises: Receiving a flag indicating that the maximum transmission delay time is an infinite value, And upon receipt of the flag, the server sends all frames of the stream to the client. The method of claim 1, further comprising: e) determining, based on the maximum transmission delay time, the maximum number of retransmissions representing the number of times the server retransmits a packet that has not been transmitted to the client, And when the corresponding frame is transmitted to the client, the server retransmits the maximum retransmission limit. The method of claim 10, wherein the maximum retransmission number is

Where Nmax is the maximum number of retransmissions, and Trt is the round trip time for one retransmission, i.e. one IP packet is sent from server to client and then back from client to server. Means the time taken. 12. The method of claim 11, wherein the retransmission is performed only when the probability of frame loss is greater than or equal to a predetermined threshold. The method of claim 12, wherein the frame loss probability is

And Pfrm is a frame loss probability, Ppkt is a packet loss probability, and N is a number of packets included in the frame. The method of claim 13, wherein the packet loss probability is

Where Ppkt is the probability of packet loss, and P0 is the probability that the corresponding UDP packet will be lost when the UDP packet is sent from server to client or from client to server (1-total received packets / total transmitted). Number of packets), where M is the number of times a packet is transmitted as it is routed from server to client or from client to server before the frame is considered out of date data. In the streaming method for transmitting a stream containing one or more frames from the streaming server to the streaming client, a) receiving from the client a suggested value of the maximum transmission lead time determined based on the real-time playback streaming rate of the client; b) determining a maximum transmission lead time based on the suggested value of the maximum transmission lead time; And c) transmitting, by the server, the stream to the client while selectively outputting only a frame having a transmission leading time less than the maximum transmission leading time from the transmission buffer to the transmission line for real time reproduction of the stream. How to. 16. The method of claim 15, wherein step c) includes maintaining a frame having a transmission leading time greater than the maximum transmission leading time in the transmission buffer until the transmission leading time becomes the maximum transmission leading time. Characterized in that. 16. The method of claim 15, wherein the suggested value of the maximum transmission lead time is included in a header of an application protocol. The method of claim 15, wherein b), b1) calculating a total real time playing condition bandwidth (BW_rt) satisfying real time playing conditions of all other clients currently connected to the server; b12) calculating an available bandwith (BW_avail) by subtracting the total real-time playback condition bandwidth (Realtime Bandwith) from the total bandwidth (BW_ch) of a transmission line; b13) calculating an allowable transmission lead time (Ta_allow) which is an allowable transmission lead time for the first client for each frame based on the free bandwidth and the streaming rate requested by the first client; And b14) determining the maximum transmit prefix time (Ta_max) allowable to the first client by selecting any value among the values smaller than the allowable transmit prefix time. 19. The method of claim 18, wherein the total real time playback condition bandwidth is the sum of the real time playback rates of each streaming of all other clients connected to the server. The method of claim 15, wherein the transmission leading time is

Where Ta (i) is the transmission delay time of the I-frame, T _actual (i) is the actual transmission time of the I-frame, and T _realtime (i) is the I-frame of the Means a transmission time. The method of claim 20, wherein the transmission time T _realtime (i) of the I-th frame satisfying the real time reproduction condition is

Is generated based on the stream start time, that is, the transmission time of the first frame transmitted by the server, Tst (1) is the timestamp of the first frame, and Tst (i) is the timestamp of the Ith frame. Characterized in that the method. 16. The method of claim 15, further comprising d) receiving the stream by a client, wherein the minimum receive buffering time of the client is equal to or greater than the maximum transmit leading time. 23. The method of claim 22, wherein the maximum transmission lead time is included in a header of an application protocol and transmitted from the server to the client. In the streaming method for transmitting a stream containing one or more frames from the server to the client, a) receiving from the client a suggested value of the maximum transmission rate determined based on the real-time playback streaming rate of the client; b) determining a maximum transmission rate, which is the maximum rate streamable to the client, based on the network load on other clients connected to the server; And c) if the maximum transmission rate is equal to or greater than the proposed transmission rate of the maximum transmission rate, transmitting the stream to the client according to the proposal of the maximum transmission rate. 25. The method of claim 24, further comprising: if the maximum transmission rate is less than the suggested value of the maximum transmission rate, sending a non-transmittable message to the client indicating that streaming is not possible with the suggested value of the maximum transmission rate. Characterized in that. The method of claim 24, wherein b), b11) calculating a total real time playback condition bandwidth that satisfies the real time playback conditions of all other clients currently connected to the server; b12) determining the maximum transmission rate by subtracting the total real time playback condition bandwidth from the total bandwidth of the transmission line. A computer-readable recording medium having recorded thereon a program for executing the method of claim 1 on a computer.

Images