Problem with rtp live streaming and 'computer too
Locked
 
|
It is critical that you include the caps line, including the
s-props-parameter string, that the 'sender' generates when you start the receiver. A correct set of caps on the reciever will look something like: "application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264, \ sprop-parameter-sets=\"Z2QAHqwkqAtD2wFQgAAB9IAAdTAHixdQ,aO8yyLA=\", \ ssrc=(guint)204906444,payload=(int)96,clock-base=(guint)3249570813,seqnum-base=(guint)5734" Note that it is critical that you properly escape spaces, commas, + signs, etc - or the receiver will not start correctly. Good luck! > Message: 3 > Date: Fri, 09 Apr 2010 18:03:38 -0600 > From: Mark Sauer <[hidden email]> > Subject: [gst-devel] Problem with rtp live streaming and 'computer too > slow' message > To: [hidden email] > Message-ID: <[hidden email]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I've been trying to set up a gstreamer graph (using gst-launch, as well > as a C application) to receive a multicasted rtp video sequence encoded > with a mpeg 2 transport stream, using h.264 video and aac audio, and > rendering it to a window. > > I have a graph that works pretty well, and it is described by this call > to gst-launch: > > gst-launch-0.10.exe udpsrc uri=udp://224.0.22.1:40000 > caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, > encoding-name=(string)MP2T-ES, payload=(int)33" ! gstrtpbin latency=4000 > ! rtpmp2tdepay ! mpegtsdemux name=a a. ! queue ! ffdec_h264 ! > ffmpegcolorspace ! b. b. ! autovideosink a. ! queue ! faad ! > audioconvert ! b. b. ! autoaudiosink multiqueue max-size-bytes=0 > max-size-buffers=40000 max-size-time=0 name=b > > I have a live encoder streaming to the address 224.0.22.1 on port > 40000. The window pops up with this graph, and the video/audio play > fine for a few minutes, sometimes even up to 20-30 minutes. But more > often after about 1-2 minutes I start seeing lots of messages like this > in the console: > > ..\..\libs\gst\base\gstbasesink.c(2572): gst_base_sink_is_too_late (): > /GstPipeline:pipeline0/GstDshowVideoSink:dshowvideosink0: > There may be a timestamping problem, or this computer is too slow. > > This is repeated over and over, and the video becomes very choppy, as > many frames are dropped. My computer is not too slow, gstreamer uses > only about 10% of one cpu to decode this stream (it is 720x480 at 1 mbps). > > I have tried this under both Windows (using the dshowvideosink), and > under linux (using the xvimagesink and ximagesink). The problem seems > to always occur, although it is worse on Windows. > > I am wondering if I am doing something wrong here, and/or if it is a > gstreamer bug? > > Thanks, > Mark Sauer ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Problem with rtp live streaming and 'computer too
Administrator
|
> It is critical that you include the caps line, including the > s-props-parameter string, that the 'sender' generates when you start > the receiver. > A correct set of caps on the reciever will look something like: > "application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264, \ > sprop-parameter-sets=\"Z2QAHqwkqAtD2wFQgAAB9IAAdTAHixdQ,aO8yyLA=\", \ ? ssrc=(guint)204906444,payload=(int)96,clock-base=(guint)3249570813,seqnum-base=(guint)5734" Admitting ignorance, but what in the world does "Z2QAHqwkqAtD2wFQgAAB9IAAdTAHixdQ,aO8yyLA" mean and how on earth would you ever know it? Wes p.s. If this actually turns into a long discussion, I'll move it to a new thread. ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by quackking
>> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Problem with rtp live streaming and 'computer too
|
|
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
|
Re: Problem with rtp live streaming and 'computer too
|
|
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 > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > > > ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |