rtpbin + mpegtsmux
Locked
rtpbin + mpegtsmux
 
|
Re: rtpbin + mpegtsmux
|
|
Re: rtpbin + mpegtsmux
|
|
Re: rtpbin + mpegtsmux
|
|
In reply to this post by Gary Thomas
> Sadly, even though the server is pumping out data, I don't see
> anything at the client (my xvimagesink window never opens up) > > Any ideas what I'm doing wrong or how to diagnose this? YouÅe probably not sending the data for the decoder to start decoding (NAL 7/8). Try starting the decoder before the sender and see if you get video decoded. If so, add a recent h264parser in the chain and it should remultiplex the correct data into the stream for the decoder to start decoding. Why are you first putting your data into TS and then again in RTP? -- greetz, marc Measure twice, cut once. crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
signature.asc (204 bytes)
Re: rtpbin + mpegtsmux
|
|
Re: rtpbin + mpegtsmux
|
|
Re: rtpbin + mpegtsmux
|
|
> > Because that's what the customer wants :-)
Is this what the customer really wants (getting video reliably over the network) or is it what you've been told the customer wants :-) > > My understanding is that TS is a container that will eventually contain > > both video and audio and is not network worthy by itself, hence the RTP > > (RealTime [network] protocol) You might have some problems with the timestamps that are in the RTP header and those that are in TS. If only one is slightly off; you'll run into problems. > That said, I've also tried this with a raw H264 stream and the same > thing happens. > > As I've pointed out, these pipelines do not even work reliably on > my desktop system all the time. Using just the raw H264 stream, I > stream out and in on my desktop, using the local network (127.0.0.1) > While it may work, even for a while, after some time the receiver no > longer gets new frames (motion stops). > > Is there some way to get useful debug information on this? I don't > see any messages about the RTP stream until level 4 and then it's > too low level to interpret easily. I'd like to know when packets > come in, how they are parsed, passed on, etc, where the keyframes > are, etc. This sort of data doesn't seem to show up in the debug > data. we've had many problems. There are a number of things you need to take into account. There are a number of encoders that only send NAL 7/8 once. You can configure the rtp payloader to re-multipex those on a regular interval in your stream. In your case; that will not work since it's not h264 you're sending, but h264/ts. That's why you can also instruct the h264 parser to re-include those settings into the stream (before you add the mpeg ts layer). Our focus is mainly on rtp/h264; but AFAIK; streaming is stable, both from hardware sources as from x264 sources (and file based). -- greetz, marc E = MC ** 2 +- 3db crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: rtpbin + mpegtsmux
|
|
Re: rtpbin + mpegtsmux
|
|
In reply to this post by Gary Thomas
-- greetz, marc Chemistry professors never die, they just fail to react. crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux > I have had a little success today, but it's still not great. I have to > have the client started before the server starts, so I'm guessing that > I have the "only one NAL" issue you mention above. How can I change the > behaviour as you mention above? I think I already mailed to on Saturday :-) barco@mgsserver001:~$ gst-inspect rtph264pay |grep config-interval config-interval : Send SPS and PPS Insertion Interval in seconds (sprop parameter sets will be multiplexed in the data stream when detected.) (0 = disabled) barco@mgsserver001:~$ gst-inspect h264parse |grep config-interval config-interval : Send SPS and PPS Insertion Interval in seconds (sprop parameter sets will be multiplexed in the data stream when detected.) (0 = disabled) > When it does run, I see messages like this on the client/receiver: > > WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A lot of buffers are being dropped. > Additional debug info: > gstbasesink.c(2686): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: > There may be a timestamping problem, or this computer is too slow. Is this pure RTP or RTP/TS? -- greetz, marc The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth. -- Niels Bohr crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: rtpbin + mpegtsmux
|
|
In reply to this post by Gary Thomas
> Do I need this on both ends? My version of h264parse (0.10.19) doesn't support
> that option. No, we put the option first in rtph264pay and then afterwards in h264parse. If you use it in the parser with an interval of 1s, adding it in the payloader will do nothing. It was added in the parser for exactly the kind of 'strange' combinations that you are trying; sending h264 in TS, in TS/RTP or even in ES over the network. You need this NAL insertion on the sending side only; since this is essential data for the decoder to start decoding. >> Is this pure RTP or RTP/TS? > > These results are RTP/TS. When I do just RTP, I never get anything other than the initial [incomplete] frame. This is probably what I was talking about; try to send it in pure RTP first and see if you get the sender/receiver working correctly. IIRC, when receiving this combination; the timestamps in the buffers are set with RTP and then afterwards adjusted with the TS timing info. I've also been warned several times that the mpegtsmux/mpegtsdemux is not completely correct with timestamps. > Note: I'm using a special H264 encoder (based on the DSP in my processor, not x264enc) That does not really matter as long as your timestamps in your encoder is correct; we're doing basically the same thing with all kinds of boards. > I tried to use x264enc, but my sensor only does UYVY: > gst-launch -vv v4l2src ! video/x-raw-yuv,width=720,height=480 ! ffmpegcolorspace ! x264enc ! filesink location=/tmp/xx > Pipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video0' cannot capture in the specified format > Additional debug info: > gstv4l2object.c(1971): gst_v4l2_object_set_format (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: > Tried to capture in YUYV, but device returned format UYVY UYVY does not seem to supported in ffmpegcolorspace > I tried to recode it, but I get an error I don't understand: > gst-launch -vv v4l2src ! video/x-raw-yuv,width=720,height=480 ! ffmpegcolorspace ! 'video/x-raw-yuv,format=(fourcc)YUY2' ! x264enc ! filesink location=/tmp/xx > WARNING: erroneous pipeline: could not link ffmpegcsp0 to x264enc0 It can't match the caps; so it can't link ffmpegcolorspace to x264enc; x264enc only supports I420 (gst-inspect x264enc) > Sorry for all the questions, but my exploration of the documentation has not > been very fruitful (I'm not always this challenged...) nah, there is a lot of information; you just need to find out where. IRC has always been helpful for me. -- greetz, marc One man's "magic" is another man's engineering. "Supernatural" is a null word. -- Robert Heinlein crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |