CN104394117A - RTP packet transmission method and device - Google Patents
RTP packet transmission method and device Download PDFInfo
- Publication number
- CN104394117A CN104394117A CN201410085286.8A CN201410085286A CN104394117A CN 104394117 A CN104394117 A CN 104394117A CN 201410085286 A CN201410085286 A CN 201410085286A CN 104394117 A CN104394117 A CN 104394117A
- Authority
- CN
- China
- Prior art keywords
- rtp
- header
- bag
- field
- compression
- 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.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Abstract
The invention discloses an RTP packet transmission method and device. The method comprises carrying out compressing on RTP headers of one or more RTP packets in a RTP packet to be transmitted, wherein the compressed RTP headers comprise serial numbers; and transmitting the RTP packet. According to the technical scheme provided in the invention, each RTP packet in conversation does not need to be transmitted with a complete RTP header, thereby reducing redundant transmission information and improving network utilization efficiency.
Description
Technical field
The present invention relates to the communications field, the transmission method wrapped in particular to a kind of RTP and device.
Background technology
Before audio, video data transmits in a network, to first encapsulate it, as being first packaged into RTP (Real-time Transport Protocol, referred to as RTP) bag, User Datagram Protoco (UDP) (the User Datagram Protocol be packaged into again, referred to as UDP) bag, internet protocol (InternetProtocol, referred to as IP) bag etc.After encapsulation, data are far longer than original valid data, cause only transmitting a small amount of audio, video data, but occupy a large amount of bandwidth.
Real-time Transport Protocol describes the normal data packet format transmitting Voice & Video on the internet in detail, and it is designed to a multicast protocol at the beginning, but is usually used in afterwards in unicast application.As shown in Figure 1, front 12 bytes of RTP packet head form appear in each RTP bag, when RTP information source is frequency mixer, also need CSRC list, sometimes also need to increase extension header.The header information of RTP bag comprises following territory: version (V), filling mark (P), extension flag (X), CSRC counting (CC), mark (M), PT Payload Type (PT) and synchronisation source information (SSRC) etc.Wherein, there is following meaning in these territories:
Version (V): 2 bits, this territory defines the version of RTP.The version of this protocol definition is 2.(value 1 is used by RTP draft version, and value 0 is used in the agreement that " vat " voice tool uses at first.)
Fill mark (P): 1 bit, if filler bit is set up, then this handbag is attached to the filling bit of end containing one or more, and filling bit not can be regarded as a part for load.Last byte of filling indicates can ignore how many filling bits.Filling may be used for the cryptographic algorithm that some has regular length, or wraps for transmitting multiple RTP in bottom data unit.
Extension flag (X): 1 bit, if arrange extended bit, gland (only) follows a head expansion below.
CSRC counts (CC): 4 bits, and CSRC counting contains the number of following CSRC identifier after gland.
Mark (M): 1 bit, the explanation of mark is specified by concrete agreement.It is used for allowing to mark important event in the bitstream, as frame boundaries.
PT Payload Type (PT): 7 bits, this territory defines the form of load, determines that it is explained by embody rule.Agreement can between specified loads type codes and load format one acquiescence coupling.Other loadtype code can by non-RTP method Dynamic Definition.RTP transmitting terminal sends an independent RTP loadtype in any preset time; Multiplexing different Media Stream need not be carried out in this territory.
Sequence number: 16 bits, often send a RTP packet, sequence number adds 1, and receiving terminal can detect packet loss accordingly and rebuild packet sequence.The initial value of sequence number is random (unpredictable), even if to make itself not encrypt in source time (sometimes bag will pass through translater, it can do like this), also can be more difficult to the general plain text attack known of cryptographic algorithm.
Timestamp: 32 bits, timestamp reflects the sampling time of first character joint in RTP packet.Clock frequency depends on load data form, and is described in description document (profile).Also can by RTP method to load format Dynamic profiling.
In same RTP session, for the header information encapsulated, very most of transmission set up after can not change, only have the data of a few byte to change.Although always there is several byte to change in each bag, the difference between bag and bag is constant, and namely second order difference is 0.Therefore, each RTP in session is wrapped, if all transmit complete RTP header, will a large amount of information redundancies be produced.
Summary of the invention
The invention discloses transmission method and the device of a kind of RTP bag, at least to solve in correlation technique, each RTP in session is wrapped, if all transmit complete RTP header, will the problem of a large amount of information redundancies be produced.
According to an aspect of the present invention, the transmission method that a kind of RTP wraps is provided.
The transmission method that RTP according to the present invention wraps comprises: compress the RTP header of RTP bag one or more in RTP bag to be transmitted, wherein, the RTP header after compression comprises: sequence number; Above-mentioned RTP bag to be transmitted is transmitted.
According to a further aspect in the invention, the transmitting device that a kind of RTP wraps is provided.
The transmitting device that RTP according to the present invention wraps comprises: compression module, and for compressing the RTP header of RTP bag one or more in RTP bag to be transmitted, wherein, the RTP header after compression comprises: sequence number; Transport module, for transmitting above-mentioned RTP bag to be transmitted.
By the present invention, compress the RTP header of RTP bag one or more in RTP bag to be transmitted, the RTP header after compression comprises sequence number information.Therefore, do not need to transmit complete RTP header to each RTP bag in session, effectively reduce the transmission information of redundancy, improve the utilization ratio of network.
Accompanying drawing explanation
Fig. 1 is the form schematic diagram of the unpressed RTP header in correlation technique;
Fig. 2 is the flow chart of the transmission method wrapped according to the RTP of the embodiment of the present invention;
Fig. 3 is the form schematic diagram of the RTP header after compressing according to the preferred embodiment of the invention;
Fig. 4 is that transmitting terminal sends the schematic flow sheet of RTP bag according to the preferred embodiment of the invention;
Fig. 5 is that receiving terminal receives the schematic flow sheet of RTP bag according to the preferred embodiment of the invention;
Fig. 6 is the structured flowchart of the transmitting device wrapped according to the RTP of the embodiment of the present invention; And
Fig. 7 is the structured flowchart of the transmitting device of RTP bag according to the preferred embodiment of the invention.
Embodiment
Below in conjunction with Figure of description, specific implementation of the present invention is made a detailed description.
Fig. 2 is the flow chart of the transmission method wrapped according to the RTP of the embodiment of the present invention.As shown in Figure 2, the transmission method that this RTP wraps comprises following process:
Step S201: compress the RTP header of RTP bag one or more in RTP bag to be transmitted, wherein, the RTP header after compression comprises: sequence number;
Step S203: above-mentioned RTP bag to be transmitted is transmitted.
In correlation technique, each RTP in session is wrapped, if all transmit complete RTP header, will a large amount of information redundancies be produced.The method shown in Fig. 1 of employing, compress the RTP header of RTP bag one or more in RTP bag to be transmitted, the RTP header after compression comprises sequence number information.Therefore, do not need to transmit complete RTP header to each RTP bag in session, effectively reduce the transmission information of redundancy, improve the utilization ratio of network.
Preferably, the RTP header after above-mentioned compression can also comprise: be used to indicate the header of current RTP bag whether through the first field of overcompression.Such as, retain the V field in the header in correlation technique, V field can be arranged to 1,2, or 3; If 1, to represent that RTP header is through compression; If 2 or 3, represent that RTP header is without compression.Wherein, if be set to 2, represent that this RTP message transmission source does not support this RTP compression scheme; If be set to 3, represent that this RTP message transmission source supports this RTP compression scheme, recipient needs to separate the contextual information extruding header and comprise sequence number and timestamp etc., and save, former RTP header can be reduced according to these contextual informations to make the RTP header of subsequently received compression.
Preferably, the RTP header after above-mentioned compression also comprise following one of at least: what be used to indicate that above-mentioned RTP bag carries is the second field of voice data or video data; Be used to indicate above-mentioned RTP and wrap the video data present frame carried three field whether vicissitudinous relative to the timestamp of previous frame; And filling field.
In preferred implementation process, when the RTP header after compression comprises: sequence number, first field, when the second field, the 3rd field and filling field, can by the compresses in length of RTP header to 2 bytes, such as, above-mentioned first field can be provided with 2 bits, and above-mentioned second field can be provided with 1 bit, and above-mentioned 3rd field can be provided with 1 bit, above-mentioned filling field can be provided with 4 bits, and above-mentioned sequence number can be provided with 8 bits.
Below in conjunction with Fig. 3, above-mentioned preferred implementation is further described.
Fig. 3 is the form schematic diagram of the RTP header after compressing according to the preferred embodiment of the invention.As shown in Figure 3,
RTP head after compression only has two bytes, compared with the uncompressed RTP header shown in Fig. 1, saves 10 bytes.Wherein, in header, V field version number still retains, and is used to indicate this RTP header and whether whether supports this RTP compression scheme through overcompression and this RTP message transmission source, be equivalent to above-mentioned first field; It is audio frequency or video data that video field is used to indicate the data that this RTP carries, and is equivalent to above-mentioned second field; Flag is used for video data timestamp and calculates, and whether video data can indicate this frame to change relative to previous frame timestamp by flag value, is equivalent to above-mentioned 3rd field; Pad field is above-mentioned filling field, can first reserve, and wouldn't use.In same audio or video rtp streaming, the information of real change is sequence number and timestamp, and sequence number increases progressively successively, the difference of the adjacent bag of voice data timestamp is also certain, such as, the bag that sequence number is adjacent increases progressively 1, and timestamp increases progressively as fixed value.If the difference of adjacent R TP bag timestamp is 40ms, if to receive sequence number be the RTP bag timestamp of n is N, then sequence number is the timestamp of m is exactly N+ (m-n) * 40, thus can calculate the timestamp information of audio frequency and video according to sequence number.
Preferably, above-mentioned RTP bag is carried out transmission comprise: in above-mentioned RTP bag, after one or more RTP bags of header uncompressed are sent, the header sending predetermined quantity wraps through the RTP of overcompression, wherein, the sequence number in the RTP header after compression wraps as benchmark increases progressively one by one with one or more RTP of above-mentioned header uncompressed.
The RTP header of compression, can be the difference with an adjacent upper RTP package informatin, also can be the difference with a upper complete RTP header.If adopt the former, the header information deviation of adjacent two RTP bag should be less, needs the difference of transmission also less, if but when having RTP packet loss, RTP header and the uncompressed front information of reduction will be inconsistent.Thus preferably adopt the latter, namely depend on previous complete RTP header to reduce RTP header information.And if previous complete RTP header interval is far away, the deviation of generation is larger, to such an extent as to the head of compression cannot carry all difference information, thus at set intervals, again must send complete RTP header.
Complete RTP header is likely lost in Internet Transmission, and the RTP header after this compressed cannot be reduced into correct information, can resend complete RTP information, but the time delay of Internet Transmission can affect the efficiency of this mechanism by receiving terminal request transmitting terminal.Can adopt and send 2 continuously, the RTP information that 3 (or more) is complete, again RTP packet header is subsequently compressed, for general network, the probability of continuous 3 packet loss is extremely low, thus can think that recipient always can receive complete RTP header information, thus can reduce the RTP header of subsequent compression.
In a rtp streaming only having sequence number and timestamp to change, because the RTP preamble sequence number of compression only has 8 (bit), thus can only transmit at most the RTP message of 256 compressions continuously.And in order to reduce the dependence of wrapping same complete RTP, the number sending compressed rtp bag continuously suitably can be reduced, such as, after sending 50 continuously, send out 3 complete RTP bags again.
Above-mentioned preferred implementation is further described below in conjunction with Fig. 4.
Fig. 4 is that transmitting terminal sends the schematic flow sheet of RTP bag according to the preferred embodiment of the invention.As shown in Figure 4, the flow process of transmitting terminal transmission RTP bag mainly comprises following process:
Namely step S401: transmitting terminal judges this send mode is that transmit head wraps through the RTP of overcompression, or transmit head is without the RTP bag (complete RTP bag) of compression.Do you particularly, judge that aud_send_lite_hdr is TURE? if so, then step S403 is performed, otherwise, perform step S409.
Step S403: transmit head wraps through the RTP of overcompression, wherein, the V field of the RTP header of compression is 1, the sequence number seq_number of the RTP header of this compression is the value of aud_send_lite_seq, aud_send_cnt increases 1, the RTP bag compressed to the header sent continuously counts, and aud_send_lite_seq is from increasing 1.
Step S405: judge that the number aud_send_lite_seq that continuous transmit head wraps through the RTP of overcompression is more than or equal to default first threshold SEND_RTP_LITE_HEADER_COUNT? if not, then RTP bag is directly sent; If so, then step S407 is performed.
Step S407: need to change another kind of send mode into, namely the RTP bag of uncompressed header is sent, aud_send_lite_hdr is set to FALSE, aud_send_cnt is set to zero, this is arranged on when sending RTP bag next time and just can comes into force, send RTP bag afterwards, RTP bag that this sends remains RTP header through overcompression.
Step S409: transmit head is without the RTP bag (complete RTP bag) of compression, and wherein, the V field of unpressed RTP header is 3, and count the complete RTP bag sent continuously, namely aud_send_cnt is from increasing 1.
Step S411: when transmission source supports this compression scheme, i.e. aud_support_lite_hdr=TRUE; And is the number aud_send_cnt judging to send continuously complete RTP bag no is more than or equal to default Second Threshold SEND_RTP_FIXED_HEADER_COUNT? if so, step S413 is performed; Otherwise, send RTP bag.
Step S413: need to change another kind of send mode into, namely the RTP bag that transmit head is compressed, aud_send_lite_hdr is set to TURE, aud_send_cnt is set to zero, aud_send_lite_seq is set to 1, this be arranged on next time send RTP bag time just come into force, afterwards send RTP bag, this send RTP bag remain RTP header without compress.
As can be seen here, before sending RTP bag, judge whether RTP header compresses, and counting is wrapped to the compressed RTP bag of the header sent continuously or complete RTP, after reaching certain number of times, change next time and send in another way.As running fire three complete RTP bags, and then send the RTP bag of 50 compressions continuously, circulate according to this.
For receiving terminal, after above-mentioned RTP bag transmits by transmitting terminal, following process can be comprised: receive above-mentioned RTP and wrap; Judge that whether the header of the current RTP bag received is through overcompression according to above-mentioned first field; If not, then upgrade local contextual information, wherein, above-mentioned contextual information comprises sequence number; If so, then according to the RTP header after the contextual information reduction compression of this locality.
Above-mentioned preferred implementation is further described below in conjunction with Fig. 5.
Fig. 5 is that receiving terminal receives the schematic flow sheet of RTP bag according to the preferred embodiment of the invention.As shown in Figure 5, the flow process of receiving terminal reception RTP bag comprises following process:
Step S501: receiving terminal receives RTP bag.
Step S503: receiving terminal judges the V field in RTP packet head.If V=1, perform step S505; If V=2, perform step S511; If V=3, perform step S513.
Step S505: receiving terminal judges the Video field in RTP packet head, if this field is 1, then performs step S509; If this field is 0, then perform step S507;
Step S507: separate and extrude sequence number seq_number, calculates sequence number and the timestamp of this RTP bag according to the sequence number and timestamp that are kept at this locality.
Step S509: separate and extrude sequence number seq_number, calculates the sequence number of this RTP bag according to the sequence number being kept at this locality.
Step S511: separate and extrude sequence number and timestamp.
Step S513: separate and extrude sequence number and timestamp, and be kept at this locality, aud_support_lite_hdr field is set to TRUE.
Fig. 6 is the structured flowchart of the transmitting device wrapped according to the RTP of the embodiment of the present invention.As shown in Figure 6, the transmitting device that this RTP wraps comprises: compression module 60, and for compressing the RTP header of RTP bag one or more in RTP bag to be transmitted, wherein, the RTP header after compression comprises: sequence number; And transport module 62, for above-mentioned RTP bag to be transmitted is transmitted.
Adopt the device shown in Fig. 6, the RTP header of compression module 60 to RTP bag one or more in RTP bag to be transmitted compresses, and the RTP header after compression comprises sequence number information.Therefore, do not need to transmit complete RTP header to each RTP bag in session, effectively reduce the transmission information of redundancy, improve the utilization ratio of network.
Preferably, the RTP header after above-mentioned compression also comprises: be used to indicate the header of current RTP bag whether through the first field of overcompression.
Preferably, the RTP header after above-mentioned compression also comprise following one of at least: what be used to indicate that above-mentioned RTP bag carries is the second field of voice data or video data; Be used to indicate above-mentioned RTP and wrap the video data present frame carried three field whether vicissitudinous relative to the timestamp of previous frame; And filling field.
Preferably, above-mentioned transport module 62, for in above-mentioned RTP bag, after one or more RTP bags of header uncompressed are sent, the header sending predetermined quantity wraps through the RTP of overcompression, wherein, the sequence number in the RTP header after compression wraps as benchmark increases progressively one by one with one or more RTP of above-mentioned header uncompressed.
Preferably, as shown in Figure 7, said apparatus also comprises: receiver module 64, wraps for receiving above-mentioned RTP; According to above-mentioned first field, judge module 66, for judging that whether the header of the current RTP bag received is through overcompression; Update module 68, for exporting as time no at above-mentioned judge module, upgrade local contextual information, wherein, above-mentioned contextual information comprises above-mentioned sequence number; Recovery module 70, for when above-mentioned judge module exports as being, according to the RTP header after the contextual information reduction compression of this locality.
Wherein, above-mentioned compression module 60 and transport module 62 can be arranged on transmitting terminal, and above-mentioned receiver module 64 and judge module 66 can be arranged on receiving terminal.
It should be noted that, the preferred implementation that in said apparatus, each module be combined with each other see the description of Fig. 2 to Fig. 5, can repeat no more herein.
In sum, by above-described embodiment provided by the invention, after sending uncompressed head, by part removing unchanged in packet header subsequently, only can transmit the change difference with a upper uncompressed head, thus reach the object of compression.Receiving terminal, by a upper uncompressed head reduction compressing head complete information, needs at local maintenance contextual information, and after receiving new uncompressed head, upgrades contextual information.The RTP header-compressed that original length can be at least 12 by RTP header suppression function is 2 bytes, thus reduces RTP shared by header information and wrap the ratio of total size, improves the utilization ratio to network.
Be only several specific embodiment of the present invention above, but the present invention is not limited thereto, the changes that any person skilled in the art can think of all should fall into protection scope of the present invention.
Claims (11)
1. a transmission method for realtime transmission protocol RTP bag, is characterized in that, comprising:
Compress the RTP header of RTP bag one or more in RTP bag to be transmitted, wherein, the RTP header after compression comprises: sequence number;
Described RTP bag to be transmitted is transmitted.
2. method according to claim 1, is characterized in that, the RTP header after described compression also comprises: be used to indicate the header of current RTP bag whether through the first field of overcompression.
3. method according to claim 1 and 2, is characterized in that, the RTP header after described compression also comprise following one of at least: what be used to indicate that described RTP bag carries is the second field of voice data or video data; Be used to indicate described RTP and wrap the video data present frame carried three field whether vicissitudinous relative to the timestamp of previous frame; And filling field.
4. method according to claim 3, it is characterized in that, the length of the RTP header after described compression is 2 bytes, wherein, described first field is provided with 2 bits, and described second field is provided with 1 bit, and described 3rd field is provided with 1 bit, described filling field is provided with 4 bits, and described sequence number is provided with 8 bits.
5. method according to claim 2, is characterized in that, described RTP bag to be transmitted is carried out transmission and comprises:
In described RTP bag, after one or more RTP bags of header uncompressed are sent, the header sending predetermined quantity wraps through the RTP of overcompression, and wherein, the sequence number in the RTP header after compression wraps as benchmark increases progressively one by one with one or more RTP of described header uncompressed.
6. method according to claim 2, is characterized in that, after being transmitted by described RTP bag to be transmitted, also comprises:
Receive described RTP bag to be transmitted;
Judge that whether the header of the current RTP bag received is through overcompression according to described first field;
If not, then upgrade local contextual information, wherein, described contextual information comprises sequence number;
If so, then according to the RTP header after the contextual information reduction compression of this locality.
7. a transmitting device for realtime transmission protocol RTP bag, is characterized in that, comprising:
Compression module, for compressing the RTP header of RTP bag one or more in RTP bag to be transmitted, wherein, the RTP header after compression comprises: sequence number;
Transport module, for transmitting described RTP bag to be transmitted.
8. device according to claim 7, is characterized in that, the RTP header after described compression also comprises: be used to indicate the header of current RTP bag whether through the first field of overcompression.
9. the device according to claim 7 or 8, is characterized in that, the RTP header after described compression also comprise following one of at least: what be used to indicate that described RTP bag carries is the second field of voice data or video data; Be used to indicate described RTP and wrap the video data present frame carried three field whether vicissitudinous relative to the timestamp of previous frame; And filling field.
10. device according to claim 8, it is characterized in that, described transport module, for in described RTP bag, after one or more RTP bags of header uncompressed are sent, the header sending predetermined quantity wraps through the RTP of overcompression, and wherein, the sequence number in the RTP header after compression wraps as benchmark increases progressively one by one with one or more RTP of described header uncompressed.
11. devices according to claim 8, is characterized in that, described device also comprises:
Receiver module, for receiving described RTP bag to be transmitted;
According to described first field, judge module, for judging that whether the header of the current RTP bag received is through overcompression;
Update module, for exporting as time no at described judge module, upgrade local contextual information, wherein, described contextual information comprises described sequence number;
Recovery module, for when described judge module exports as being, according to the RTP header after the contextual information reduction compression of this locality.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410085286.8A CN104394117A (en) | 2014-03-10 | 2014-03-10 | RTP packet transmission method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410085286.8A CN104394117A (en) | 2014-03-10 | 2014-03-10 | RTP packet transmission method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN104394117A true CN104394117A (en) | 2015-03-04 |
Family
ID=52611953
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410085286.8A Pending CN104394117A (en) | 2014-03-10 | 2014-03-10 | RTP packet transmission method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104394117A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017118273A1 (en) * | 2016-01-04 | 2017-07-13 | 中兴通讯股份有限公司 | Method and device for transmitting and receiving timestamp information |
| WO2018054193A1 (en) * | 2016-09-23 | 2018-03-29 | 杭州海康威视数字技术股份有限公司 | Data transmission method and apparatus, and electronic device |
| CN109257772A (en) * | 2017-07-13 | 2019-01-22 | 普天信息技术有限公司 | A kind of sending, receiving method and user equipment of RTP data |
| CN110784679A (en) * | 2019-03-12 | 2020-02-11 | 宋彤云 | Communication load big data adjusting method and storage medium |
| CN111246521A (en) * | 2020-01-15 | 2020-06-05 | 四川安迪科技实业有限公司 | Method and device for compression sending, receiving and self-learning of satellite transmission network packet header |
| CN112584134A (en) * | 2020-12-07 | 2021-03-30 | 深圳市捷视飞通科技股份有限公司 | Method and device for testing video conference code stream, computer equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101119300A (en) * | 2007-08-28 | 2008-02-06 | 华为技术有限公司 | Method and device for limiting bandwidth |
| CN101350812A (en) * | 2008-08-22 | 2009-01-21 | 上海华为技术有限公司 | Data transmission method, communication apparatus and communication system |
| CN102484643A (en) * | 2009-07-08 | 2012-05-30 | 汤姆森特许公司 | Backward looking robust header compression receiver |
| CN102629927A (en) * | 2012-04-09 | 2012-08-08 | 华为技术有限公司 | Receiving and transmitting method and device as well as processing system for RTP (Real-time Transport Protocol) media data |
-
2014
- 2014-03-10 CN CN201410085286.8A patent/CN104394117A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101119300A (en) * | 2007-08-28 | 2008-02-06 | 华为技术有限公司 | Method and device for limiting bandwidth |
| CN101350812A (en) * | 2008-08-22 | 2009-01-21 | 上海华为技术有限公司 | Data transmission method, communication apparatus and communication system |
| CN102484643A (en) * | 2009-07-08 | 2012-05-30 | 汤姆森特许公司 | Backward looking robust header compression receiver |
| CN102629927A (en) * | 2012-04-09 | 2012-08-08 | 华为技术有限公司 | Receiving and transmitting method and device as well as processing system for RTP (Real-time Transport Protocol) media data |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017118273A1 (en) * | 2016-01-04 | 2017-07-13 | 中兴通讯股份有限公司 | Method and device for transmitting and receiving timestamp information |
| WO2018054193A1 (en) * | 2016-09-23 | 2018-03-29 | 杭州海康威视数字技术股份有限公司 | Data transmission method and apparatus, and electronic device |
| CN107872422A (en) * | 2016-09-23 | 2018-04-03 | 杭州海康威视数字技术股份有限公司 | A kind of data transmission method, device and electronic equipment |
| CN107872422B (en) * | 2016-09-23 | 2020-01-10 | 杭州海康威视数字技术股份有限公司 | Data transmission method and device and electronic equipment |
| US10869106B2 (en) | 2016-09-23 | 2020-12-15 | Hangzhou Hikvision Digital Technology Co., Ltd. | Data transmission method and apparatus, and electronic device |
| CN109257772A (en) * | 2017-07-13 | 2019-01-22 | 普天信息技术有限公司 | A kind of sending, receiving method and user equipment of RTP data |
| CN110784679A (en) * | 2019-03-12 | 2020-02-11 | 宋彤云 | Communication load big data adjusting method and storage medium |
| CN110784679B (en) * | 2019-03-12 | 2020-10-16 | 王虎 | Communication load big data adjusting method and storage medium |
| CN111246521A (en) * | 2020-01-15 | 2020-06-05 | 四川安迪科技实业有限公司 | Method and device for compression sending, receiving and self-learning of satellite transmission network packet header |
| CN112584134A (en) * | 2020-12-07 | 2021-03-30 | 深圳市捷视飞通科技股份有限公司 | Method and device for testing video conference code stream, computer equipment and storage medium |
| CN112584134B (en) * | 2020-12-07 | 2022-10-21 | 深圳市捷视飞通科技股份有限公司 | Method and device for testing video conference code stream, computer equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104394117A (en) | RTP packet transmission method and device | |
| KR101722719B1 (en) | Backward looking robust header compression receiver | |
| JP6523249B2 (en) | Method and apparatus for compressing packet header | |
| KR101835340B1 (en) | Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal | |
| KR101122143B1 (en) | Signaling buffer parameters indicative of receiver buffer architecture | |
| CN108183774A (en) | The forward error correction and system of a kind of streaming media | |
| CN100591053C (en) | Packet transmission method and network node device | |
| JP2004208292A (en) | Control traffic compression method | |
| US9392082B2 (en) | Communication interface and method for robust header compression of data flows | |
| CN103973645A (en) | Data transmission method and data transmission device | |
| CN103825869A (en) | Compression and decompression method for Ethernet message header, and compression and decompression device thereof | |
| CN101459654A (en) | Multi-protocol service data package parsing method, receiving terminal and sending terminal | |
| CN104270594B (en) | The method and apparatus that data packet sends and receives | |
| CN101453463B (en) | Data packet packing, transmitting and receiving method for mobile multimedia broadcast system | |
| CN106303537B (en) | A kind of more code stream transmission methods of openh264 | |
| CN101505420B (en) | Encapsulation method for video compression data | |
| US8804766B2 (en) | Method and apparatus for compressing communication packets | |
| CN101197825A (en) | Method, system and device for compression message transmission | |
| CN107517202B (en) | Binary sending and receiving method of SIP signaling | |
| CN108574684B (en) | Decompression method and device | |
| CN113132766B (en) | VBR (visual basic) sending method of TS (transport stream) packaging format | |
| CN108737349B (en) | Voice data packet processing method and device | |
| KR101331095B1 (en) | compressed transmission method for XML massages based on OMA DM, and system thereof | |
| CN104780182A (en) | HTTP chunked coding and IP packet packaging and analyzing method | |
| CN104394119A (en) | RTP packet sending method and device as well as responding method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20150304 |
|
| RJ01 | Rejection of invention patent application after publication |