FMUSER Wirless Transmit Video And Audio More Easier !
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org ->Afrikaans
sq.fmuser.org ->Albanian
ar.fmuser.org ->Arabic
hy.fmuser.org ->Armenian
az.fmuser.org ->Azerbaijani
eu.fmuser.org ->Basque
be.fmuser.org ->Belarusian
bg.fmuser.org ->Bulgarian
ca.fmuser.org ->Catalan
zh-CN.fmuser.org ->Chinese (Simplified)
zh-TW.fmuser.org ->Chinese (Traditional)
hr.fmuser.org ->Croatian
cs.fmuser.org ->Czech
da.fmuser.org ->Danish
nl.fmuser.org ->Dutch
et.fmuser.org ->Estonian
tl.fmuser.org ->Filipino
fi.fmuser.org ->Finnish
fr.fmuser.org ->French
gl.fmuser.org ->Galician
ka.fmuser.org ->Georgian
de.fmuser.org ->German
el.fmuser.org ->Greek
ht.fmuser.org ->Haitian Creole
iw.fmuser.org ->Hebrew
hi.fmuser.org ->Hindi
hu.fmuser.org ->Hungarian
is.fmuser.org ->Icelandic
id.fmuser.org ->Indonesian
ga.fmuser.org ->Irish
it.fmuser.org ->Italian
ja.fmuser.org ->Japanese
ko.fmuser.org ->Korean
lv.fmuser.org ->Latvian
lt.fmuser.org ->Lithuanian
mk.fmuser.org ->Macedonian
ms.fmuser.org ->Malay
mt.fmuser.org ->Maltese
no.fmuser.org ->Norwegian
fa.fmuser.org ->Persian
pl.fmuser.org ->Polish
pt.fmuser.org ->Portuguese
ro.fmuser.org ->Romanian
ru.fmuser.org ->Russian
sr.fmuser.org ->Serbian
sk.fmuser.org ->Slovak
sl.fmuser.org ->Slovenian
es.fmuser.org ->Spanish
sw.fmuser.org ->Swahili
sv.fmuser.org ->Swedish
th.fmuser.org ->Thai
tr.fmuser.org ->Turkish
uk.fmuser.org ->Ukrainian
ur.fmuser.org ->Urdu
vi.fmuser.org ->Vietnamese
cy.fmuser.org ->Welsh
yi.fmuser.org ->Yiddish
1. Introduction to RTP
RTP is a real-time transmission protocol which provides end-to-end transmission service, which supports the transmission of real-time data in single target broadcast and multi-objective broadcast network service, while the real-time data transmission is monitored and controlled by RTCP protocol.
2. RTP is defined in RFC
The application using RTP protocol runs on RTP, while the program executing RTP runs on the upper layer of UDP, in order to use the port number and check and of UDP. RTP can be regarded as a sub layer of the transport layer. The audio and TV data blocks generated by multimedia applications are encapsulated in RTP packets, each RTP packet is encapsulated in UDP message segment, and then packaged in IP packets.
The structure of the packet includes several domains widely used in multimedia, including audio on demand, video on demand, Internet telephone and videoconference. RTP specification does not set standards for compressed formats for sound and television, and it can be used to transmit files in normal format. For example, sound in wav or GSM (Global System for mobile communications), MPEG-1 and MPEG-2 TV can also be used to transmit sound and TV files stored in proprietary formats.
From the perspective of application developers, RTP executors can be considered as part of the application because developers must integrate RTP into the application. At the sending end, developers must write the program executing RTP protocol into the application program that creates RTP information package, and then the application program sends RTP information package to socket interface of UDP, as shown in Figure 2; Similarly, RTP packets are input to the application through UDP socket interface at the receiver. Therefore, developers must write the program executing RTP protocol to the application that extracts media data from RTP packet.
The paper takes RTP as an example to illustrate its working process. Suppose the sound of the sound source is a PCM encoded sound of 64 kb / s, and assume that the application takes 20 ms of encoded data as a chunk, that is, 160 bytes of sound data in a data block. The application needs to add RTP title to this sound data to generate RTP packets, which include the type, sequence number and timestamp of the sound data. RTP packets are then sent to the UDP socket interface, where they are encapsulated in the UDP packets. At the receiver, the application program receives RTP information package from the socket interface, extracts the sound data block from RTP information package, and then decodes and plays sound correctly using the information in the title field of RTP packet.
If the application does not use proprietary solutions to provide payload type, sequence number or timestamp, but uses standard RTP protocol, the application will be easier to run with other network applications, which is what everyone hopes. For example, if two different companies are developing Internet phone software, they all incorporate RTP into their products, which is hopeful that users using different company phone software can communicate.
It is important to emphasize that RTP does not provide any mechanism to ensure that data is delivered to the receiver in time or other service quality. It does not guarantee that the information package is not lost or the order of packets is not disturbed. Indeed, RTP encapsulation can only be seen on the system side. The router in the middle does not distinguish that IP datagram carries RTP packets.
RTP allows each media source to be assigned a separate RTP packet stream, such as a camera or microphone. For example, a television conference with two groups involved could open four packet streams: two cameras transmitting TV streams and two microphones to transmit sound streams. However, many popular coding technologies, including MPEG-1 and MPEG-2, bind sound and TV images together to form a single data stream in the coding process, and generate a RTP packet stream in one direction.
RTP packets are not limited to single target broadcasting, and they can also be transmitted on one to many multi-target broadcast tree or multi-to-many multi-target broadcast tree. For example, multi-target broadcast with multiple to many, in this application, all the transmitting terminals usually send their RTP packet stream to the multi-objective broadcast tree with the same multi-objective broadcast address.
3. RTP packet header field
RTP title consists of four packet header fields and other domains: payload type domain, sequence number domain, timestamp domain and synchronization source identifier domain.
1) payload type
The payload type field in RTP packet is 7 bits long, so RTP can support 128 different payload types. For sound flow, this field is used to indicate the type of coding used by sound, such as PCM, adaptive delta modulation, linear predictive coding, and so on. If the sender decides to change the encoding method during the session or broadcast, the sender can notify the receiver through this domain. Table 1 lists the types of sound payloads that RTP can support at present.
For TV streams, payload types can be used to indicate the type of TV coding, such as motion JPEG, MPEG-1, MPEG-2, h.231, etc. The sender can also change the encoding method of TV at any time during the session or during the session. Table 16-02 lists some TV payloads types that RTP can support at present.
2) serial number
The sequence number field field is 16 bits long. Add 1 to each RTP packet sequence number. The receiver can use it to check whether the packet is missing and process the packet according to the sequence number. For example, the receiving application receives a RTP packet stream, which has an interval between sequence numbers 86 and 89, and the receiver knows that packets 87 and 88 have been lost and take measures to process the lost data.
3) timestamp
The timestamp domain is 32 bytes long. It reflects the sampling time (time) of the first byte in the RTP packet. The receiver can use this timestamp to remove the jitter of the packets caused by the network, and provide synchronization function for playback at the receiving end.
4) synchronization source identifier
The length of the synchronization source identifier (SSRC) domain is 32 bits. It is used to identify the origin of RTP packet flow, and each packet flow during RTP session or period has a clear SSRC. SSRC is not the IP address of the sender, but a number randomly assigned by the source at the beginning of the new packet flow.
|
Enter email to get a surprise
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org ->Afrikaans
sq.fmuser.org ->Albanian
ar.fmuser.org ->Arabic
hy.fmuser.org ->Armenian
az.fmuser.org ->Azerbaijani
eu.fmuser.org ->Basque
be.fmuser.org ->Belarusian
bg.fmuser.org ->Bulgarian
ca.fmuser.org ->Catalan
zh-CN.fmuser.org ->Chinese (Simplified)
zh-TW.fmuser.org ->Chinese (Traditional)
hr.fmuser.org ->Croatian
cs.fmuser.org ->Czech
da.fmuser.org ->Danish
nl.fmuser.org ->Dutch
et.fmuser.org ->Estonian
tl.fmuser.org ->Filipino
fi.fmuser.org ->Finnish
fr.fmuser.org ->French
gl.fmuser.org ->Galician
ka.fmuser.org ->Georgian
de.fmuser.org ->German
el.fmuser.org ->Greek
ht.fmuser.org ->Haitian Creole
iw.fmuser.org ->Hebrew
hi.fmuser.org ->Hindi
hu.fmuser.org ->Hungarian
is.fmuser.org ->Icelandic
id.fmuser.org ->Indonesian
ga.fmuser.org ->Irish
it.fmuser.org ->Italian
ja.fmuser.org ->Japanese
ko.fmuser.org ->Korean
lv.fmuser.org ->Latvian
lt.fmuser.org ->Lithuanian
mk.fmuser.org ->Macedonian
ms.fmuser.org ->Malay
mt.fmuser.org ->Maltese
no.fmuser.org ->Norwegian
fa.fmuser.org ->Persian
pl.fmuser.org ->Polish
pt.fmuser.org ->Portuguese
ro.fmuser.org ->Romanian
ru.fmuser.org ->Russian
sr.fmuser.org ->Serbian
sk.fmuser.org ->Slovak
sl.fmuser.org ->Slovenian
es.fmuser.org ->Spanish
sw.fmuser.org ->Swahili
sv.fmuser.org ->Swedish
th.fmuser.org ->Thai
tr.fmuser.org ->Turkish
uk.fmuser.org ->Ukrainian
ur.fmuser.org ->Urdu
vi.fmuser.org ->Vietnamese
cy.fmuser.org ->Welsh
yi.fmuser.org ->Yiddish
FMUSER Wirless Transmit Video And Audio More Easier !
Contact
Address:
No.305 Room HuiLan Building No.273 Huanpu Road Guangzhou China 510620
Categories
Newsletter