CN108377427B - Real-time video transmission method and system - Google Patents
Real-time video transmission method and system Download PDFInfo
- Publication number
- CN108377427B CN108377427B CN201810083545.1A CN201810083545A CN108377427B CN 108377427 B CN108377427 B CN 108377427B CN 201810083545 A CN201810083545 A CN 201810083545A CN 108377427 B CN108377427 B CN 108377427B
- Authority
- CN
- China
- Prior art keywords
- packet
- data packet
- interval
- sending
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64784—Data processing by the network
- H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
- H04N21/6405—Multicasting
Abstract
The invention relates to a real-time video transmission method and a real-time video transmission system. The method comprises the steps that a sending end divides a video stream into data packets and sends the data packets out in sequence, and the initial sending time and the last sending time of the data packets are recorded; the receiving end receives the data packet, judges whether the data packet has packet loss, disorder or repetition according to the number, and records the serial number of the lost packet; receiver per interval negative acknowledgement interval t1Checking lost data packet, if yes, packaging the serial number of lost data packet and serial number range of received data packet in negative acknowledgement packet, sending to sending end, every positive acknowledgement interval t2Checking the lost data packet, if no packet is lost, packaging the sequence number range of the received data packet in a positive confirmation packet, and sending the positive confirmation packet to the sending end; a sending end receives confirmation packets from each receiving end and counts the receiving number and the loss number; and judging whether retransmission is needed or not, and if so, retransmitting. The method and the system of the invention combine a positive confirmation mechanism and a negative confirmation mechanism to better cope with the sudden packet loss and the data delay.
Description
Technical Field
The invention belongs to the field of video data transmission, and particularly relates to a real-time video transmission method and a real-time video transmission system.
Background
Wireless transmission technologies such as Wireless Local Area Networks (WLANs) are widely used for small-scale high-capacity data communication, such as transmitting real-time video streams in a classroom or conference room. However, compared to wired transmission, wireless transmission has the disadvantages of high error rate and high packet loss rate, so that the transmission quality of real-time video stream is affected. In order to overcome the problem of packet loss, measures can be taken at different levels of a network protocol stack, for example, the 802.11 protocol can perform retransmission for a limited number of times in a unicast mode, so that the packet loss rate can be controlled to be below 0.1%; the TCP protocol can completely overcome packet loss through retransmission of a transmission layer; however, the above measures are only applicable to unicast mode. In order to conserve bandwidth, it is often desirable to employ multicast or broadcast modes in one-to-many video transmissions. In multicast or broadcast mode, the 802.11 protocol and UDP protocol do not retransmit, which often results in an unacceptably high final packet loss rate (e.g., 2% -10%), resulting in severe image degradation of the video stream.
In order to reduce or eliminate the problem of packet loss in multicast or broadcast mode, various reliable multicast protocols have been proposed in the industry, such as NORM, PGM, etc. The core idea generally includes letting the receiving end detect the packet loss, and send a Negative Acknowledgement (NAK) to the transmitting end, letting the transmitting end retransmit the lost packet.
These reliable multicast protocols do enable reliable data transmission (i.e., eliminating packet loss), but often do not optimize the delay of data transmission sufficiently, and multiple retransmissions can cause a large delay. The transmission of real-time video streams requires high picture quality, but at the same time requires sufficiently low picture delay, and a good real-time video multicast protocol needs to reasonably take into account the requirements of both aspects.
Another challenge of high packet loss rate networks such as WLANs is that packet loss tends to be bursty, i.e., most of the time the packet loss rate is at a low level, but for a short period of time (e.g., 0.1-2 seconds), the packet loss rate becomes very high or even completely unavailable, which is usually caused by bursty interference or obstruction (e.g., pedestrians). During these periods, the aforementioned negative acknowledgement packet (NAK) may also be lost, and for this reason, measures such as repeatedly sending the negative acknowledgement packet need to be taken to ensure reliable transmission, which increases both delay and network bandwidth occupation.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to provide a real-time video transmission method and a real-time video transmission system, which can solve the problem of sudden packet loss in a multicast or broadcast mode.
In order to achieve the above purposes, the invention adopts the technical scheme that: a real-time video transmission method, comprising the steps of:
(1) a sending end divides a video stream into data packets suitable for transmission in sequence, numbers the data packets in sequence, and attaches the numbers to the data packets for transmission;
(2) the sending end sends the data packets out in sequence and records the initial sending time and the last sending time of each data packet;
(3) the receiving end receives the data packet, judges whether the data packet has packet loss, disorder or repetition according to the number, corrects the disorder and the repetition data packet according to the judgment result, and records the sequence number of the lost packet;
(4) receiver per interval negative acknowledgement interval t1Checking the lost data packet, if yes, packaging the serial number of the lost data packet and the serial number range of the received data packet in a negative confirmation packet, sending to the sending end,
receiving end every interval positive acknowledgement interval t2Checking the lost data packet, if no packet is lost, packaging the sequence number range of the received data packet in a positive confirmation packet, and sending the positive confirmation packet to the sending end;
(5) a sending end receives confirmation packets from each receiving end and counts the receiving number and the loss number of each data packet;
(6) and judging that each data packet needs to be retransmitted or abandons retransmission.
Further, the transmitting end and the receiving end transmit in a broadcast or multicast mode.
Further, the step (6) specifically includes: if the negative acknowledgement retransmission interval t is at the last transmission time of the data packet3Then the number of losses exceeds the minimum negative acknowledgment number n1Retransmitting the data packet;
if the correct acknowledgement retransmission interval t is at the last transmission time of the data packet4Then, the number of losses does not exceed the minimum negative acknowledgment number n1And the sum of the received number and the lost number does not exceed the minimum number of acknowledgements n2Then the packet is retransmitted.
Further, the step (6) further comprises: if the time of a data packet from the initial transmission exceeds the abandon retransmission interval t5Then the retransmission is aborted.
Further, the receiving end submits the data packet sequence without packet loss and the data packet sequence which is abandoned by the sending end for retransmission to the next-stage processing step.
Further, the minimum negative acknowledgment number n1And a minimum number of acknowledgements, n2And determining according to the total number of the receiving ends according to a preset proportion.
Further, the total number of the receiving end is estimated in real time through the acknowledgement packet received by the receiving end.
Further, a negative acknowledgement interval t1Correct acknowledgement interval t2At least 50% smaller.
Further, a negative acknowledgement retransmission interval t3Greater than the negative acknowledgement interval t1And a negative acknowledgement retransmission interval t3And a negative acknowledgement interval t1Belong to the same order of magnitude;
positive acknowledgement retransmission interval t4Greater than the positive acknowledgement interval t2And correct acknowledgement retransmission interval t4And correct acknowledgement interval t2Belonging to the same order of magnitude.
A real-time video transmission system comprising: the system comprises a sending end and at least one receiving end;
the sending end is used for segmenting the video stream into data packets in sequence, sending out the data packets in sequence, recording the initial sending time and the last sending time of each data packet, receiving the confirmation packets from each receiving end, counting the receiving number and the loss number of each data packet, judging whether each data packet needs to be retransmitted or not, and retransmitting if so;
the receiving end is used for receiving the data packet, judging whether the data packet has packet loss, disorder or repetition according to the number, correcting the disorder and the repetition data packet according to the judgment result, recording the sequence number of the lost packet, and confirming the interval t every interval of negative1Checking lost data packet, if there is, packaging the serial number of lost data packet and the serial number range of received data packet in a negative acknowledgement packet, sending to the sending end, and sending positive acknowledgement interval t at every interval2And checking the lost data packet, if the lost data packet does not exist, packaging the sequence number range of the received data packet in a positive confirmation packet, and sending the positive confirmation packet to the sending end.
The invention has the following effects: the method and the system have the following remarkable technical effects:
1. and combining the positive acknowledgement mechanism and the negative acknowledgement mechanism, thereby better dealing with the problem of sudden packet loss. In a protocol which only depends on a negative acknowledgement mechanism, a data packet and a related negative acknowledgement packet may be lost together due to sudden packet loss, so that a sending end cannot know that the data packet needs to be retransmitted; in order to overcome this difficulty, the receiving end needs to send the same negative acknowledgement packet multiple times, or the sending end needs to acknowledge the negative acknowledgement packet, which wastes bandwidth resources. By adding the correct acknowledgement mechanism, the sending end can guess that the sudden packet loss occurs, so that remedial retransmission is performed.
2. The interval for sending the negative acknowledgement packet is smaller, and the interval for sending the correct acknowledgement packet is larger, so that the bandwidth occupied by the acknowledgement packet is not excessively increased, and the lower data delay under the normal condition (stable packet loss rate) is ensured. Although the present invention is mainly directed to the transmission of video streams, the application scope is not limited thereto, and the present invention can also be used for any streaming multicast/broadcast with high real-time requirement and large data volume.
3. The situation that the receiving end joins and withdraws in and out dynamically and often can be adapted.
Drawings
FIG. 1 is a schematic flow chart of an embodiment of the method of the present invention;
FIG. 2 is a schematic diagram of an embodiment of the system of the present invention.
Detailed Description
In order to make the technical problems solved, the technical solutions adopted, and the technical effects achieved by the present invention clearer, the technical solutions of the embodiments of the present invention will be further described in detail with reference to the accompanying drawings. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention.
As shown in fig. 1, fig. 1 is a schematic flow chart of an embodiment of the method of the present invention. The method comprises the following steps:
in a specific embodiment, there are 1 sender and N receivers, and the video stream is transmitted in multicast mode. Both the sending end and the receiving end add an IP multicast address, and agree on a UDP port number for sending/receiving data packets, and agree on another port number for sending/receiving acknowledgement packets. Specifically, the typical value of N is 25-100.
In other embodiments, the video stream may also be transmitted in a broadcast mode, as follows.
It is noted that the negative acknowledgement interval t is referred to hereinafter1Greater than the out-of-order arrival of packets and less than the expected average data delay time. To reduce the number of negative acknowledgement packets, reduce the network load, t1Nor should it be too small. In a specific embodiment, assuming that the network layer round trip delay is 5ms, the sender sends 100 packets per second on average (10 ms one on average), and the expected average data delay is 100ms, then t can be calculated1Is defined as 50 ms.
Positive acknowledgement interval t2Less than maximum data delay t6And to reduce the number of correct acknowledgement packets. In a specific embodiment, if t is required6Not more than 1200ms, t may be set2Is defined as 1000 ms. Wherein the maximum data delay t6Can be determined according to the maximum allowable picture delay, and the maximum data delay t6Less than the maximum picture delay allowed.
I.e. negative acknowledgement interval t1Significantly smaller than the correct acknowledgement interval t2. Specifically, the negative acknowledgement interval t1 is greater than the correct acknowledgement interval t2At least 50% smaller.
Minimum negative acknowledgment number n1Minimum number of confirmations n2Negative acknowledgement retransmission interval t3Correct acknowledgement retransmission interval t4Giving up retransmission interval t5The value of (c) can be determined as follows:
minimum negative acknowledgment number n1And a minimum number of acknowledgements, n2And determining according to the total number of the receiving ends according to a preset proportion. Wherein, the total number of the receiving end is estimated in real time through the confirmation packet received by the receiving end or obtained through a receiving end registration process. Wherein the acknowledgement packet comprises a positive acknowledgement packet and a negative acknowledgement packet. The total number of the receiving end can also repeatedly traverse all the entries in the sending state table at certain time intervals, and take the union of all the ' receiving set ' and the ' losing setCollecting to obtain a 'recent active receiving end set'; the size of the "recent active receiver set", or the average size over a period of time thereof, is taken as the new N. The initial value of N may take 1 or may be specified as the case may be.
In particular, n1Is a fraction of N, when the predetermined ratio is 5%, then N15% N. But n is1And a minimum of 1. Likewise, n2Is a fraction of N, when the predetermined ratio is 75%, then N is275% N. But n is2And a minimum of 1. The preset proportion is only for illustration, and in other embodiments, the preset proportion can be optimized according to actual conditions.
Negative acknowledgement retransmission interval t3Greater than the negative acknowledgement interval t1And a negative acknowledgement retransmission interval t3And a negative acknowledgement interval t1Belonging to the same order of magnitude. In particular, the negative acknowledgement retransmission interval t3Slightly larger than the round trip time of the network plus the negative acknowledgement interval t at the receiving end1。
Positive acknowledgement retransmission interval t4Greater than the positive acknowledgement interval t2And correct acknowledgement retransmission interval t4And correct acknowledgement interval t2Belonging to the same order of magnitude. Specifically, the correct acknowledgement retransmission interval t4Slightly larger than the round trip time of the network plus the correct acknowledgement interval t at the receiving end2. And, t4Is always greater than t3。
Abandoning retransmission intervals t5Greater than positive acknowledgement retransmission interval t4. In a particular embodiment of the present invention,
t5＝1.5*t4。
it should be further noted that, the sending end maintains a sending state table, the key of the mapping table is the number of the data packet, and the value is a tuple: [ packet, initial transmission time, last transmission time, next collection, missing set ]. The "reception set" and the "loss set" are sets of unique identifiers of the receiving end that received and lost the packet, respectively, and the sizes of the two sets are called reception number and loss number, respectively. The unique identifier of the receiving end may be represented by its IP address, or generated randomly.
The receiving end maintains a receiving queue, the entries of which are tuples: [ packet number, packet, reception time ]. The receive queue is a priority queue, i.e., its entries are always in ascending order of packet number. Initially, the receive queue is empty.
The initial values of the numerical variables 'the last dequeue number' and 'the last confirmation end number' are all 0, namely, the minimum data packet number (1) is subtracted by 1; the variable "last confirmation time", is the current time at the beginning; the set "last negative acknowledgement number set" is initially an empty set.
Step 101: the sending end divides the video stream into data packets according to the sequence, numbers the data packets according to the sequence, and attaches the numbers to the data packets for transmission.
The sending end obtains the video data stream (such as from a camera) in a certain way, and divides the video data stream into data packets (such as 1KB) with the size suitable for network transmission, and the data packets are added with numbers. The numbering may be generated sequentially in ascending order (e.g., 1, 2, 3, 4).
Step 102: and the sending end sends the data packets out in sequence and records the initial sending time and the last sending time of each data packet.
In a specific embodiment, the transmitting end sequentially transmits the data packets in a multicast manner. When one is sent out, an entry is newly added in the sending state table, the initial sending time and the last sending time are set as the sending time, and the receiving set and the lost set are empty sets.
Step 103: and the receiving end receives the data packet, judges whether the data packet has packet loss, disorder or repetition according to the number, corrects the disorder and the repetition data packet according to the judgment result, and records the sequence number of the lost packet.
Because each data packet has an individual number, and the number is not changed when the data packet is retransmitted, the receiving end can detect the problems of packet loss, disorder, repetition and the like according to the number of the received data packet.
Specifically, the receiving end receives the data packet in a multicast manner. Every time a packet is received, the number is read, and it is checked whether there is an entry with the same number in the receive queue or whether the "last dequeue number" is equal to or greater than the number. If so, discarding the packet because the packet is duplicated; if not, a new entry is inserted, the number is set as the number of the packet, and the receiving time is set as the time of receiving the packet.
The number of the first entry (i.e., the lowest number, hereinafter referred to as the head of queue) in the receive queue is rechecked at a predetermined time interval. If the difference between the head of line number and the "last dequeue number" is 1, it means that there is no packet lost immediately before this data packet, and a "dequeue" operation is performed. If the difference between the queue head number and the last dequeue number is larger than 1 and the difference between the current time and the receiving time of the queue head is larger than the maximum data delay t6Then the packet between the last dequeue number and the head-of-line number is considered to be lost and the retransmission has been abandoned, so a "dequeue" operation is also performed. Immediately after each "dequeue" operation, the check for a new head of line is repeated.
The receiving end submits the data packet sequence without lost packet and the data packet sequence which is abandoned by the transmitting end to the next stage of processing. So the "dequeue" operation includes: and moving the head of the queue out of the receiving queue, submitting the data in the head of the queue to the next-stage processing step (specifically, audio and video decoding and displaying can be carried out), and setting the last dequeuing number as the number of the data packet. Wherein the predetermined time is significantly less than the negative acknowledgement interval t1I.e. preset time to negative acknowledgement interval t1At least 50% smaller.
And finally, repeatedly traversing the receiving queue according to a preset time interval, identifying the place with discontinuous numbers, namely the lost data packet, and generating a negative acknowledgement number set. Wherein the predetermined time is significantly less than the negative acknowledgement interval t1I.e. preset time to negative acknowledgement interval t1At least 50% smaller.
Specifically, if the "last acknowledgement end number" is 1 and the numbers in the receive queue include 3, 4, and 6, it indicates that the packet No. 2 and 5 are lost, and the "negative acknowledgement number set" should be {2,5 }.
Step 104: receiver per interval negative acknowledgement interval t1Checking lost data packet, if there is, packet-lost sequence numberAnd the sequence number range of the received data packet are packaged in a negative acknowledgement packet and sent to the sending end,
receiving end every interval positive acknowledgement interval t2And checking the lost data packet, if the lost data packet does not exist, packaging the sequence number range of the received data packet in a positive confirmation packet, and sending the positive confirmation packet to the sending end.
Receiver per interval negative acknowledgement interval t1And checking the lost data packet, if so, packaging the sequence number of the lost data packet and the sequence number range of the received data packet in a confirmation packet, and sending the confirmation packet to the sending end. Specifically, if the "negative acknowledgement number set" is not a subset of the "last negative acknowledgement number set", the transmitting end transmits a negative acknowledgement packet.
Better cope with the problem of sudden packet loss, the receiving end positively confirms the interval t at every interval2And checking the lost data packet, if the lost data packet does not exist, packaging the sequence number range of the received data packet in a positive confirmation packet, and sending the positive confirmation packet to the sending end. Specifically, if the negative acknowledgement number set is empty and the difference between the current time and the last acknowledgement time is greater than the positive acknowledgement interval t2The transmitting end transmits an acknowledgement packet.
In a specific embodiment, the content of the acknowledgement packet is: [ Start, end, negative confirmation number set ]. Wherein the value of "start" is the "last acknowledgement end number" +1, the value of "end" is the number of the tail of the receiving queue (if the queue is not empty) or the "last dequeue number" (if the queue is empty), both of which determine the range of acknowledgements; if the "negative acknowledgement number set" is empty, it is omitted. After transmission, the "last acknowledgement time" is set as the transmission time, the "last acknowledgement end number" is set as the value of "end", and the "last negative acknowledgement number set" is replaced with the "negative acknowledgement number set".
Step 105: the sending end receives the confirmation packets from each receiving end, and counts the receiving number and the loss number of each data packet.
The sending end continuously monitors the confirmation packets sent by the receiving end, and the confirmation packets comprise positive confirmation packets and negative confirmation packets. When an acknowledgement packet is received, the sequence number of the received data packet and the sequence number of the lost packet are read out and updated to the corresponding entry in the transmission status table. For example, if the receiving end 10.0.0.5 sends an acknowledgement packet with the content "range 2-6, loss 3, 5", then "10.0.0.5" is added to the receiving set of entries with sequence numbers 2, 4, 6 and the loss set of entries with sequence numbers 3, 5. Skipping if an entry for the corresponding sequence number does not exist. The sizes of the receiving set and the loss set are respectively called receiving number and loss number, and the receiving number and the loss number of each data packet are counted.
Step 106: and judging that each data packet needs to be retransmitted or abandons retransmission.
The judgment conditions are as follows:
if the negative acknowledgement retransmission interval t is at the last transmission time of the data packet3Then the number of losses exceeds the minimum negative acknowledgment number n1Then the packet is retransmitted. In particular, the sending state table is traversed repeatedly at preset time intervals (significantly less than t3, i.e. at least 50% less) if the number of losses of an entry exceeds the threshold n1And the current time is greater than t from the last time of transmission field3Then the packet is retransmitted. At retransmission, the "last transmission time" field is set as the time of retransmission, and the reception set and the missing set are emptied.
If the correct acknowledgement retransmission interval t is at the last transmission time of the data packet4Then, the number of losses does not exceed the minimum negative acknowledgment number n1And the sum of the received number and the lost number does not exceed the minimum number of acknowledgements n2Then the packet is retransmitted. In particular, at preset time intervals (significantly less than t)4I.e. at least 50% less) repeatedly traverse the send state table if the number of missing entries does not exceed n1And the sum of the received number and the lost number does not exceed n2And the current time is greater than t from the last time of transmission field4Then the packet is retransmitted. At retransmission, the "last transmission time" field is set as the time of retransmission, and the reception set and the missing set are emptied.
Preferably, the two determination conditions are executed in the same cycle so that retransmission does not occur repeatedly in a short time.
If the sending end is at oneThe distance between each data packet and the initial transmission time exceeds the abandon retransmission interval t5Then the retransmission is aborted. In particular, at preset time intervals (significantly less than t)5I.e., at least 50% less) repeatedly traverse the transmission status table if the current time is greater than t from the "initial transmission time" field5Then the retransmission is aborted and the entry is deleted from the transmission status table.
And submitting the data packet sequence which is not lost by the receiving end and the data packet sequence which is abandoned by the transmitting end for retransmission to the next-stage processing step. In particular, audio and video decoding and display can be performed.
It should be noted that, although the present invention is mainly directed to the transmission of video streams, the application scope is not limited thereto, and the present invention can also be used for any streaming multicast/broadcast with high real-time requirement and large data volume.
Different from the prior art characteristics, the real-time video transmission method provided by the invention can better solve the problem of sudden packet loss by combining the positive acknowledgement mechanism and the negative acknowledgement mechanism, and the negative acknowledgement packet is transmitted at a smaller interval, while the correct acknowledgement packet is transmitted at a larger interval, so that the bandwidth occupied by the acknowledgement packet is not excessively increased, and the data delay is ensured to be lower under the normal condition (the packet loss rate is stable).
As shown in fig. 2, a real-time video transmission system 200 includes: a transmitting end 201 and at least one receiving end 202.
The sending end 201 is configured to segment a video stream into data packets in sequence, send out the data packets in sequence, record initial sending time and last sending time of each data packet, receive acknowledgement packets from each receiving end, count the number of received data packets and the number of lost data packets, determine whether each data packet needs to be retransmitted, and retransmit if necessary;
the receiving end 202 is configured to receive the data packet, determine whether the data packet has a packet loss, disorder or duplication according to the number, modify the disorder and duplication data packet according to the determination result, and record the sequence number of the lost packet, wherein each negative acknowledgement interval t is an interval1Checking the lost data packet, if any, the serial number of the lost data packet and the serial number of the received data packetThe range is packaged in a negative acknowledgement packet and sent to the sending end, and each interval is a positive acknowledgement interval t2And checking the lost data packet, if the lost data packet does not exist, packaging the sequence number range of the received data packet in a positive confirmation packet, and sending the positive confirmation packet to the sending end.
The video stream is transmitted between the sending end 201 and the receiving end 202 in a broadcast or multicast mode.
Different from the prior art characteristics, the real-time video transmission system provided by the invention can better solve the problem of sudden packet loss by combining the positive acknowledgement mechanism and the negative acknowledgement mechanism, the negative acknowledgement packet transmission interval is smaller, and the correct acknowledgement packet transmission interval is larger, so that the bandwidth occupied by the acknowledgement packet is not excessively increased, and the lower data delay under the normal condition (the stable packet loss rate) is ensured.
It will be appreciated by those skilled in the art that the method and system of the present invention are not limited to the embodiments described in the detailed description, which is for the purpose of explanation and not limitation. Other embodiments will be apparent to those skilled in the art from the following detailed description, which is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
Claims (7)
1. A method for real-time video transmission, the method comprising the steps of:
(1) a sending end divides a video stream into data packets in sequence, numbers the data packets in sequence, and attaches the numbers to the data packets for transmission;
(2) the sending end sends the data packets out in sequence and records the initial sending time and the last sending time of each data packet;
(3) the receiving end receives the data packet, judges whether the data packet has packet loss, disorder or repetition according to the number, corrects the disorder and the repetition data packet according to the judgment result, and records the sequence number of the lost packet;
(4) receiver per interval negative acknowledgement interval t1Checking the lost data packet, if any, the order of packet lossThe number and the sequence number range of the received data packet are packaged in a negative confirmation packet and sent to the sending end,
receiving end every interval positive acknowledgement interval t2Checking the lost data packet, if no packet is lost, packaging the sequence number range of the received data packet in a positive confirmation packet, and sending the positive confirmation packet to the sending end; the negative acknowledgement interval t1 is greater than the time of out-of-order arrival of packets, less than the expected average data delay time, and the negative acknowledgement interval t1 is at least 50% less than the correct acknowledgement interval t 2;
(5) a sending end receives confirmation packets from each receiving end and counts the receiving number and the loss number of each data packet;
(6) judging whether each data packet needs to be retransmitted or not, and retransmitting if the data packet needs to be retransmitted: if the negative acknowledgement retransmission interval t is at the last transmission time of the data packet3Then the number of losses exceeds the minimum negative acknowledgment number n1Retransmitting the data packet;
if the correct acknowledgement retransmission interval t is at the last transmission time of the data packet4Then, the number of losses does not exceed the minimum negative acknowledgment number n1And the sum of the received number and the lost number does not exceed the minimum number of acknowledgements n2Then the packet is retransmitted.
2. The real-time video transmission method according to claim 1, wherein the transmitting end and the receiving end transmit in a broadcast or multicast manner.
3. The real-time video transmission method according to claim 1, wherein the step (6) further comprises:
if the time of a data packet from the initial transmission exceeds the abandon retransmission interval t5Then the retransmission is aborted.
4. A real-time video transmission method as claimed in any one of claims 1 or 3, characterized in that:
the receiving end submits the data packet sequence without lost packet and the data packet sequence which is abandoned by the sending end to the next stage of processing steps.
5. A real-time video transmission method as claimed in claim 3, characterized in that:
minimum negative acknowledgment number n1And a minimum number of acknowledgements, n2And determining according to the total number of the receiving ends according to a preset proportion.
6. A real-time video transmission method as claimed in claim 1 or 3, characterized in that:
negative acknowledgement retransmission interval t3Greater than the negative acknowledgement interval t1And a negative acknowledgement retransmission interval t3And a negative acknowledgement interval t1Belong to the same order of magnitude;
positive acknowledgement retransmission interval t4Greater than the positive acknowledgement interval t2And correct acknowledgement retransmission interval t4And correct acknowledgement interval t2Belonging to the same order of magnitude.
7. A real-time video transmission system, comprising: the system comprises a sending end and at least one receiving end;
the sending end is used for segmenting the video stream into data packets in sequence and sending out the data packets in sequence, recording the initial sending time and the last sending time of each data packet, receiving the acknowledgement packets from each receiving end, counting the receiving number and the loss number of each data packet, and if the negative acknowledgement retransmission interval t is the negative acknowledgement retransmission interval t of the last sending time of the data packet3Then the number of losses exceeds the minimum negative acknowledgment number n1Retransmitting the data packet;
if the correct acknowledgement retransmission interval t is at the last transmission time of the data packet4Then, the number of losses does not exceed the minimum negative acknowledgment number n1And the sum of the received number and the lost number does not exceed the minimum number of acknowledgements n2Retransmitting the data packet;
the receiving end is used for receiving the data packet, judging whether the data packet has packet loss, disorder or repetition according to the number, correcting the disorder and the repetition data packet according to the judgment result, recording the sequence number of the lost packet, and confirming the interval t every interval of negative1Checking for lost data packetsIf yes, packaging the sequence number of the lost packet and the sequence number range of the received data packet in a negative confirmation packet, and sending the negative confirmation packet to the sending end, wherein each positive confirmation interval t is arranged2Checking the lost data packet, if no packet is lost, packaging the sequence number range of the received data packet in a positive confirmation packet, and sending the positive confirmation packet to the sending end; the negative acknowledgement interval t1 is greater than the time of out-of-order arrival of packets, less than the expected average data delay time, and the negative acknowledgement interval t1 is at least 50% less than the correct acknowledgement interval t 2.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810083545.1A CN108377427B (en) | 2018-01-29 | 2018-01-29 | Real-time video transmission method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810083545.1A CN108377427B (en) | 2018-01-29 | 2018-01-29 | Real-time video transmission method and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108377427A CN108377427A (en) | 2018-08-07 |
| CN108377427B true CN108377427B (en) | 2021-11-26 |
Family
ID=63016871
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810083545.1A Active CN108377427B (en) | 2018-01-29 | 2018-01-29 | Real-time video transmission method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108377427B (en) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109274980A (en) * | 2018-09-19 | 2019-01-25 | 北京文香信息技术有限公司 | A kind of data transmission method for being quickly broadcast live |
| CN109660749B (en) * | 2018-12-22 | 2021-04-09 | 成都毅创空间科技有限公司 | Entrance guard communication device |
| CN109842821A (en) * | 2018-12-25 | 2019-06-04 | 视联动力信息技术股份有限公司 | A kind of method and apparatus of video data transmission |
| CN111385069A (en) * | 2018-12-27 | 2020-07-07 | 广州市百果园信息技术有限公司 | Data transmission method and computer equipment |
| CN110225419A (en) * | 2019-05-15 | 2019-09-10 | 深圳市麦谷科技有限公司 | A kind of packet loss repeating method for realizing flow control |
| CN110417644A (en) * | 2019-07-29 | 2019-11-05 | 中国工商银行股份有限公司 | The message method and device of instant messaging |
| CN110545486B (en) * | 2019-08-05 | 2022-04-05 | 广州珠江数码集团股份有限公司 | Video signal transmission method, device, medium and terminal equipment |
| CN112398797B (en) * | 2019-08-19 | 2023-05-02 | 贵州白山云科技股份有限公司 | Data transmission method, receiving device, transmitting device, medium, equipment and system |
| CN110649994B (en) * | 2019-09-27 | 2022-03-22 | 北京奇艺世纪科技有限公司 | Data transmission control method, related device and storage medium |
| CN111263240B (en) * | 2020-02-12 | 2022-07-19 | 青岛海信宽带多媒体技术有限公司 | IPTV4K audio and video playing management method and device and display equipment |
| CN114598628A (en) * | 2020-12-04 | 2022-06-07 | 中兴通讯股份有限公司 | Network packet loss detection method, electronic device and computer readable storage medium |
| CN113973215A (en) * | 2021-10-25 | 2022-01-25 | 北京字节跳动网络技术有限公司 | Data deduplication method and device and storage medium |
| CN114531210B (en) * | 2022-02-03 | 2024-01-26 | 百果园技术(新加坡)有限公司 | Data retransmission method, device, electronic equipment and storage medium |
| CN114978433B (en) * | 2022-05-20 | 2023-12-05 | 百度时代网络技术（北京）有限公司 | Data transmission method, apparatus, device, storage medium and computer program product |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101075948A (en) * | 2006-05-15 | 2007-11-21 | 中兴通讯股份有限公司 | Method for realizing realtime fluid-medium programm reliable transmission |
| CN101304302A (en) * | 2008-06-06 | 2008-11-12 | 广东威创视讯科技股份有限公司 | Method and system for transmitting video data |
| CN101714915A (en) * | 2009-11-02 | 2010-05-26 | 清华大学 | Data retransmission method and system |
| US7782851B2 (en) * | 2007-06-26 | 2010-08-24 | At&T Intellectual Property I, L.P. | System and method of detecting lost video data packets |
| CN102546081A (en) * | 2010-12-21 | 2012-07-04 | 中兴通讯股份有限公司 | Packet loss detection method, system and media client |
| CN102857440A (en) * | 2012-08-17 | 2013-01-02 | 杭州华三通信技术有限公司 | Data processing method and switchboard |
| CN103780971A (en) * | 2012-10-23 | 2014-05-07 | 北京网动网络科技股份有限公司 | RUDP-based real-time video transmission method under internet condition |
| CN104244109A (en) * | 2014-09-19 | 2014-12-24 | 浙江宇视科技有限公司 | Method and device for reliably transmitting and receiving media streams |
| CN106330289A (en) * | 2015-06-19 | 2017-01-11 | 中广联合移动电视系统有限公司 | Big data satellite network transmission system |
| CN106341241A (en) * | 2016-08-18 | 2017-01-18 | 北京海誉动想科技股份有限公司 | High-packet-loss-rate cloud system file multicast method and device |
| CN106911485A (en) * | 2017-03-16 | 2017-06-30 | 恒生电子股份有限公司 | For the method and apparatus of reliable multicast transport data |
| CN206908759U (en) * | 2017-06-14 | 2018-01-19 | 广州珠江数码集团股份有限公司 | A kind of video multicast packet loss retransmission system |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8879458B2 (en) * | 2012-04-23 | 2014-11-04 | Hewlett-Packard Development Company, L.P. | Transmission in a network with active and sleeping clients |
| US20160323062A1 (en) * | 2015-05-01 | 2016-11-03 | Ubitus Inc. | Packet recovery in interactive real-time media protocol |
-
2018
- 2018-01-29 CN CN201810083545.1A patent/CN108377427B/en active Active
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101075948A (en) * | 2006-05-15 | 2007-11-21 | 中兴通讯股份有限公司 | Method for realizing realtime fluid-medium programm reliable transmission |
| US7782851B2 (en) * | 2007-06-26 | 2010-08-24 | At&T Intellectual Property I, L.P. | System and method of detecting lost video data packets |
| CN101304302A (en) * | 2008-06-06 | 2008-11-12 | 广东威创视讯科技股份有限公司 | Method and system for transmitting video data |
| CN101714915A (en) * | 2009-11-02 | 2010-05-26 | 清华大学 | Data retransmission method and system |
| CN102546081A (en) * | 2010-12-21 | 2012-07-04 | 中兴通讯股份有限公司 | Packet loss detection method, system and media client |
| CN102857440A (en) * | 2012-08-17 | 2013-01-02 | 杭州华三通信技术有限公司 | Data processing method and switchboard |
| CN103780971A (en) * | 2012-10-23 | 2014-05-07 | 北京网动网络科技股份有限公司 | RUDP-based real-time video transmission method under internet condition |
| CN104244109A (en) * | 2014-09-19 | 2014-12-24 | 浙江宇视科技有限公司 | Method and device for reliably transmitting and receiving media streams |
| CN106330289A (en) * | 2015-06-19 | 2017-01-11 | 中广联合移动电视系统有限公司 | Big data satellite network transmission system |
| CN106341241A (en) * | 2016-08-18 | 2017-01-18 | 北京海誉动想科技股份有限公司 | High-packet-loss-rate cloud system file multicast method and device |
| CN106911485A (en) * | 2017-03-16 | 2017-06-30 | 恒生电子股份有限公司 | For the method and apparatus of reliable multicast transport data |
| CN206908759U (en) * | 2017-06-14 | 2018-01-19 | 广州珠江数码集团股份有限公司 | A kind of video multicast packet loss retransmission system |
Non-Patent Citations (1)
| Title |
|---|
| 基于UDP进行大规模数据传输的可靠传输系统的设计与实现;何润岸;《中国优秀硕士学位论文全文数据库》;20160430;I138-374 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108377427A (en) | 2018-08-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108377427B (en) | Real-time video transmission method and system | |
| CN108881970B (en) | Method and apparatus for transmission rate control for real-time video streaming systems | |
| US9306708B2 (en) | Method and apparatus for retransmission decision making | |
| EP2529528B1 (en) | A method and apparatus for parsing a network abstraction-layer for reliable data communication | |
| US7315898B2 (en) | Data communication system, data transmission apparatus, data reception apparatus, data communication method, and computer program | |
| US6505253B1 (en) | Multiple ACK windows providing congestion control in reliable multicast protocol | |
| DE60223799T2 (en) | METHOD AND TRANSMITTER FOR AN EFFICIENT PACKAGE DATA TRANSFER IN A TRANSMISSION PROTOCOL WITH REQUEST REQUIREMENTS | |
| CN107204834B (en) | Control method for high-speed network reliable transmission based on UDT protocol | |
| US6526022B1 (en) | Detecting congestion by comparing successive loss of packets in windows to provide congestion control in reliable multicast protocol | |
| EP1301041A1 (en) | Video data transmission method and apparatus | |
| US8423855B2 (en) | Adaptive and scalable packer error correction apparatus and method | |
| US10715284B2 (en) | Requesting retransmission of data in a multicast network | |
| CN108833930B (en) | Live broadcast data transmission control method and device, live broadcast equipment and storage medium | |
| US10505677B2 (en) | Fast detection and retransmission of dropped last packet in a flow | |
| WO2006107423A2 (en) | Error recovery mechanism and network element comprising same | |
| CN112769526B (en) | Data packet retransmission method, system and storage medium | |
| CN110602568B (en) | Video stream transmission packet loss retransmission method, device and storage device based on RTP | |
| US20050094632A1 (en) | DOCSIS MAC layer-based ARQ for fixed wireless | |
| WO2000001123A1 (en) | Congestion control in reliable multicast protocol | |
| CN113014501A (en) | Data transmission method, system, encoder and computer readable storage medium | |
| KR100911137B1 (en) | Hop-by-Hop Frame Aggregation for VoIP on Multi-Hop Wireless Networks | |
| CN117527152A (en) | Retransmission packet sending control method, system, equipment and storage medium | |
| CN116566920A (en) | Data transmission control method and related device | |
| Li et al. | An NACK Oriented Reliable Multicast Protocol over Wireless Channel |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |