gst/rtp/README: Update README with some examples.

Original commit message from CVS:
* gst/rtp/README:
Update README with some examples.
* gst/rtp/gstrtpmp4gpay.c: (gst_rtp_mp4g_pay_init),
(gst_rtp_mp4g_pay_finalize), (gst_rtp_mp4g_pay_parse_audio_config),
(gst_rtp_mp4g_pay_parse_video_config), (gst_rtp_mp4g_pay_new_caps),
(gst_rtp_mp4g_pay_setcaps):
* gst/rtp/gstrtpmp4gpay.h:
Make optional RTP parameters of type STRING, as required by the
application/x-rtp caps specification.

1 files changed, 91 insertions, 14 deletions

diff --git a/gst/rtp/README b/gst/rtp/README
index 146c55fa..129efb97 100644
--- a/gst/rtp/README
+++ b/gst/rtp/README
@@ -29,7 +29,7 @@ The following fields can or must (*) be specified in the structure:
    clock-base: (uint) [0 - MAXINT]
     The RTP time representing time 0
 
-   seqnum-base:
+   seqnum-base: (uint) [0 - MAXINT]
     The RTP sequence number representing the first rtp packet
 
    encoding-name: (String) ANY
@@ -76,19 +76,96 @@ The following fields can or must (*) be specified in the structure:
  possible.
 
 
-TODO
-----
-
-- implement packing up to the MTU.
-- discont events in the case of packet loss
-- figure out the clocking.
-- implement various RFCs dealing with different payload types. 
-  (as modules?)
-- Throw-out the the caps-nego & other session control things to the 
-  Application Developer( App ), by turning rtcp work into, signals 
-  in gstrtpsend & props/args in gstrtprecv.
-  The App would then be free to use any sort of session control 
-  protocal like RTSP.( done )
+usage with UDP
+--------------
+
+To correctly and completely use the RTP payloaders on the sender and the
+receiver you need to write an application. It is not possible to write a full
+blown RTP server with a single gst-launch line.
+
+That said, it is possible to do something functional with a few gst-launch
+lines. The biggest problem when constructing a correct gst-launch line lies on
+the receiver end. 
+
+The receiver needs to know about the type of the RTP data along with a set of
+RTP configuration parameters. This information is usually transmitted to the
+client using some sort of session description language (SDP) over some reliable
+channel (HTTP/RTSP/...).  
+
+All of the required parameters to connect and use the RTP session on the
+server can be found in the caps on the server end. The client receives this
+information in some way (caps are converted to and from SDP, as explained above,
+for example).
+
+Some gst-launch lines:
+
+  gst-launch-0.10 -v videotestsrc ! ffenc_h263p ! rtph263ppay ! udpsink
+
+   Setting pipeline to PAUSED ...
+   /pipeline0/videotestsrc0.src: caps = video/x-raw-yuv, format=(fourcc)I420,
+   width=(int)320, height=(int)240, framerate=(fraction)30/1
+   Pipeline is PREROLLING ...
+   ....
+   /pipeline0/udpsink0.sink: caps = application/x-rtp, media=(string)video,
+   payload=(int)96, clock-rate=(int)90000, encoding-name=(string)H263-1998,
+   ssrc=(guint)527842345, clock-base=(guint)1150776941, seqnum-base=(guint)30982
+   ....
+   Pipeline is PREROLLED ...
+   Setting pipeline to PLAYING ...
+   New clock: GstSystemClock
+
+ Write down the caps on the udpsink and set them as the caps of the UDP 
+ receiver:
+
+  gst-launch-0.10 -v udpsrc caps="application/x-rtp, media=(string)video,
+  payload=(int)96, clock-rate=(int)90000, encoding-name=(string)H263-1998,
+  ssrc=(guint)527842345, clock-base=(guint)1150776941, seqnum-base=(guint)30982"
+  ! rtph263pdepay ! ffdec_h263 ! xvimagesink sync=false
+
+ The receiver now displays an h263 image. Note that the sync parameter on
+ xvimagesink needs to be FALSE because we do not have an RTP session manager
+ that controls the synchronisation in this pipeline.
+
+ Stream a quicktime file with mpeg4 video and AAC audio on port 5000 and port
+ 5002.
+
+  gst-launch-0.10 -v filesrc location=~/data/sincity.mp4 ! qtdemux name=d ! queue ! rtpmp4vpay ! udpsink port=5000  
+                         d. ! queue ! rtpmp4gpay ! udpsink port=5002
+    ....
+    /pipeline0/udpsink0.sink: caps = application/x-rtp, media=(string)video,
+    payload=(int)96, clock-rate=(int)90000, encoding-name=(string)MP4V-ES,
+    ssrc=(guint)1162703703, clock-base=(guint)816135835, seqnum-base=(guint)9294,
+    profile-level-id=(string)3, config=(string)000001b003000001b50900000100000001200086c5d4c307d314043c1463000001b25876694430303334
+    /pipeline0/udpsink1.sink: caps = application/x-rtp, media=(string)audio,
+    payload=(int)96, clock-rate=(int)44100, encoding-name=(string)mpeg4-generic,
+    ssrc=(guint)3246149898, clock-base=(guint)4134514058, seqnum-base=(guint)57633,
+    encoding-params=(string)2, streamtype=(string)5, profile-level-id=(string)1,
+    mode=(string)AAC-hbr, config=(string)1210, sizelength=(string)13,
+    indexlength=(string)3, indexdeltalength=(string)3
+    ....
+
+ Again copy the caps on both sinks to the receiver launch line
+
+    gst-launch 
+     udpsrc port=5000 caps="application/x-rtp, media=(string)video, payload=(int)96,
+      clock-rate=(int)90000, encoding-name=(string)MP4V-ES, ssrc=(guint)1162703703,
+      clock-base=(guint)816135835, seqnum-base=(guint)9294, profile-level-id=(string)3,
+      config=(string)000001b003000001b50900000100000001200086c5d4c307d314043c1463000001b25876694430303334"
+      ! rtpmp4vdepay ! ffdec_mpeg4 ! xvimagesink sync=false 
+     udpsrc port=5002 caps="application/x-rtp, media=(string)audio, payload=(int)96,
+      clock-rate=(int)44100, encoding-name=(string)mpeg4-generic, ssrc=(guint)3246149898,
+      clock-base=(guint)4134514058, seqnum-base=(guint)57633, encoding-params=(string)2,
+      streamtype=(string)5, profile-level-id=(string)1, mode=(string)AAC-hbr,
+      config=(string)1210, sizelength=(string)13, indexlength=(string)3,
+      indexdeltalength=(string)3" 
+      ! rtpmp4gdepay ! faad ! alsasink sync=false
+
+ The caps on the udpsinks can be retrieved when the server pipeline prerolled to
+ PAUSED.
+
+ 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
+ as they are live sources and only produce data in PLAYING.
 
 
 Relevant RFCs