FaSTTUBe/GST-Tensordecoder-ov_ep
37
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

rtp: update README, fix some typos, mention gstrtpbin

Browse Source
This commit is contained in:
Wim Taymans 2009-06-11 22:30:06 +02:00 committed by Wim Taymans
parent 0bd984c52f
commit 6f3c1728f3
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
gst/rtp/README
View File

@ -165,7 +165,7 @@ between the RTP and GST timestamps. This information is used by a session
manager to create SR reports. The NTP time in the report will contain the manager to create SR reports. The NTP time in the report will contain the
running time converted to NTP time and the corresponding RTP timestamp. running time converted to NTP time and the corresponding RTP timestamp.
Not that at the sender side, the RTP and GStreamer timestamp both increment at Note that at the sender side, the RTP and GStreamer timestamp both increment at
the same rate, the sender rate. This rate depends on the global pipeline clock the same rate, the sender rate. This rate depends on the global pipeline clock
of the sender. of the sender.
@ -225,7 +225,7 @@ and will apply the drift correction to the GStreamer timestamp before pushing
the buffer downstream. The result is that the depayloader receives a smoothed the buffer downstream. The result is that the depayloader receives a smoothed
GStreamer timestamp on the RTP packet, which is copied to the depayloaded data. GStreamer timestamp on the RTP packet, which is copied to the depayloaded data.
The following pipeline illustrates the sender with a jitterbuffer. The following pipeline illustrates a receiver with a jitterbuffer.
gst-launch udpsrc caps="application/x-rtp, media=(string)video, gst-launch udpsrc caps="application/x-rtp, media=(string)video,
clock-rate=(int)90000, encoding-name=(string)H263-1998" ! clock-rate=(int)90000, encoding-name=(string)H263-1998" !
@ -326,6 +326,17 @@ Some gst-launch lines:
The caps on the udpsinks can be retrieved when the server pipeline prerolled to The caps on the udpsinks can be retrieved when the server pipeline prerolled to
PAUSED. PAUSED.
The above pipeline sets sync=false on the audio and video sink which means that
no synchronisation will be performed in the sinks, they play the data when it
arrives. If you want to enable synchronisation in the sinks it is highly
recommended to use a gstrtpjitterbuffer after the udpsrc elements.
Even when sync is enabled, the two different streams will not play synchronised
against eachother because the receiver does not have enough information to
perform this task. For this you need to add the gstrtpbin element in both the
sender and receiver pipeline and use additional sources and sinks to transmit
RTCP packets used for inter-stream synchronisation.
The caps on the receiver side can be set on the UDP source elements when the The caps on the receiver side can be set on the UDP source elements when the
pipeline went to PAUSED. In that state no data is received from the UDP sources pipeline went to PAUSED. In that state no data is received from the UDP sources
as they are live sources and only produce data in PLAYING. as they are live sources and only produce data in PLAYING.