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

[Mark Sauer]

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"

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
> 
> 

-- 
View this message in context: http://n4.nabble.com/Problem-with-rtp-live-streaming-and-computer-too-tp1835541p1839055.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.