Hi,<div> </div><div>Only the sound of the stream is getting corrupted. Video plays smooth still. Can this still be explained by clock skew or stream data corruption? I would suspect to see corruption or frame drops in the video too. So there is never a queue (buffering) needed to play a live udp stream?</div> <div> </div><div>Do you have more information on the gio performance issue? Could I find out somehow that my system is affected?</div> <div> </div><div>GStreamer version:</div><div>base: 0.10.36</div> <div>good: 0.10.31 </div><div>bad: 0.10.23</div><div>ugly: 0.10.19</div> <div> </div><div>Best regards,</div><div> </div><div>Christophe</div> <div class="gmail_extra"> <div class="gmail_quote">On Wed, Nov 14, 2012 at 8:24 AM, Edward Hervey <<a href="mailto:bilboed@gmail.com" target="_blank">bilboed@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi, summary: this issue doesn't require a queue to fix the issue. What version of GStreamer are you using ? The "crackling" is most likely due to clock skew happening, or data stream getting corrupted. Depending on the version of GStreamer you are using and the bitrate being used, you might want to increase the udpsrc socket buffer-size to a bigger value (buffer-size property). Also note that there is a performance issue with the underlying system being used by udpsrc (gio) which is currently being fixed. On some systems it could cause packet drops (because we don't read out the data from the socket fast enough). Edward <div class="HOEnZb"><div class="h5"> On Tue, 2012-11-13 at 21:09 +0100, Christophe Oosterlynck wrote: > Tim-Philipp, thanks for your quick and helpful reply. I'm glad I asked > here first before starting to implement something. I will try your > suggestion. > > > I'm also not sure if inserting a queue element right after the udp > source is the right way to catch my problems with udp streaming. The > actual problem I'm having is corrupted sound on playing a raw udp > stream containing a transport stream consisting of H264 video and MPEG > 1 layer 2 audio. The image is fine but the sound starts crackling > after a while until it sometimes disappears completely until it plays > fine again and repeats this in a cycle of 60 seconds. > > > As there is no buffering for live sources in playbin2, I'm suspecting > this to be a problem. Why is there no facility in playbin2 to delay > playback of a udp stream a bit to buffer it and handle possible packet > delays? > > > Best regards, > > > Christophe > > > On Tue, Nov 13, 2012 at 3:09 PM, Tim-Philipp Müller <<a href="mailto:t.i.m@zen.co.uk">t.i.m@zen.co.uk</a>> > wrote: > On Tue, 2012-11-13 at 05:40 -0800, Christophe Oosterlynck > wrote: > > > I'm looking to do the same thing. Right after the source, I > want to insert > > another element and let playbin2 do the rest. > > > > From what I see I have 2 possibilities: > > * react to "notify::source" signal, add the extra element to > the bin, link > > it to the source and let playbin2 continue > > * wait until playbin2 has finished constructing the whole > pipeline, unlink > > source and next element and insert extra element in between. > > > > Can I do one of these safely or shouldn't I fiddle with the > playbin2 > > pipeline behind its back? > > > > What I want to achieve with this: buffer a live udp source. > > The buffering mechanism in playbin2 is not usable for live > sources as you > > cannot pause them. I want to insert a queue element right > behind the udpsrc > > element with min-threshold-bytes. This works when I create a > custom pipeline > > with gst-launch. If this is not the best way to handle this, > let me know. > > Nevertheless, I'm still interested in the answer to my > question on fiddling > > with the playbin2 pipeline. > > > You should not fiddle with playbin's pipeline, and certainly > not link > elements behind its back. It won't work. Even if it does work, > it might > stop working tomorrow. And we won't even feel bad for a second > if your > app breaks doing things like that ;) > > The only sane way to do things like this is to write your own > element, > which could be a GstBin subclass where you add some source and > whatever > additional elements you want and then create a ghost source > pad. You can > then register a new (or existing, if you must) URI protocol > for it, so > if you do playbin uri=fooudp://a.b.c.d:port it will plug your > bin. > > Or you could try to come up with API for playbin to add such a > thing, > but I think would need to be rather well-justified and deemed > interesting enough to be added. > > (What does your "routine" element do, "BCXA" ?) > > Cheers > -Tim > > _______________________________________________ > gstreamer-devel mailing list > <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> > > > > _______________________________________________ > gstreamer-devel mailing list > <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </div></div></blockquote></div> </div>