[gst-devel] Problem with rtp live streaming and 'computer too

[Wim Taymans]

On Tue, 2010-04-13 at 13:50 -0800, Mark Sauer wrote:
> Thanks for your information.  I have done a quick test, and preserving all
> the caps, does seem to help, and will test this out more when I am able.  
> 
> I am wondering how one would deal with this in the case that one was using a
> different encoder.  That is, the mpeg 2 transport stream was not created by
> gstreamer?  Using gstreamer to original the rtp/udp transmission of the
> transport stream, I got caps in the form:
> 
> "application/x-rtp, media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)MP2T-ES, payload=(int)33, ssrc=(guint)2949718801,
> clock-base=(guint)630480528, seqnum-base=(guint)6088"

the payload type is fixed and the receiver will already know when
receiving the packet. ssrc, clock-base and seqnum are used only in RTSP
to improve synchronisation before RTCP is received, a receiver does not
need them to decode the stream. Also, the clock-rate, media and
encoding-name for payload type 33 is always 90000, video and MP2T-ES
respectively.

In short, a receiver can just receive this stream without requiring any
extra configuration.

Wim

> 
> But I note that the numbers in the last three settings, change each time I
> start the graph.  So I guess you are saying I need to devise a way of
> getting this information from my encoders to my decoders, so they would
> display the stream with no issues. 
> 
> I'll have to think about this.  But I am curious if you have any advice on
> how to deal with streams coming from other encoders.
> 
> Thanks,
> Mark Sauer
> 
> 
> quackking wrote:
> > 
> >>> Admitting ignorance, but what in the world does  
> >>> "Z2QAHqwkqAtD2wFQgAAB9IAAdTAHixdQ,aO8yyLA" mean and how on earth  
> >>> would you ever know it? Wes
> > 
> > This string (as is the clock-base, etc) is *generated* by gstreamer  
> > itself each time the 'capture/send' end of the pipeline is set up. The  
> > exact contents vary depending on when you start the pipeline and what  
> > your pipeline parameters are. As I understand it, the "receive" end of  
> > the pipeline needs to know this stuff in order to successfully  
> > negotiate a synchronized transfer of data. The actual negotiation  
> > details are pretty complex, and are documented in the rtp-bin code.
> > 
> > If you 'gst-launch -v ' (verbose turned on) the server (the  
> > capture/send end of the pipe) from a command line somewhere down  
> > toward the bottom of the very verbose output you will see a reference  
> > to UDP - that area will contain the actual caps that this particular  
> > setting has created. You need to somehow get that into the 'receive'  
> > (client) end of the pipeline in order to avoid the dropped packets and  
> > bad sync errors you are seeing. You are correct that the computer is  
> > *not* too slow.
> > 
> > This script mentions that the caps should be negotiated out of band.  
> > Look around for some python examples that do this - they are out there.
> > 
> > http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/rtp/client-H264-PCMA.sh
> > 
> > Good luck!
> > 
> > 
> > ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> > 
> > 
>