I have tried with rtpjitterbuffer next to udpsrc element and before of h264depay. It is possible that the repeated packets has been ignored, but, the problem persist, even with the property no-lost=true. Maybe the main problem is the network, but, it is very strange, I am using an AdHoc network and a common home network... I think that the problem is in the elements that I use to build the pipeline, or maybe, GStreamer just can not deal with IPv6. How Chinese people (who have in general IPv6) work with this kind of streams? I really need to find a solution of this issue, but, I do not know where search. I am sure that there must be a way to stablish the connection properly, after all, IPv6 supposedly is better to this kind of applications... Thanks again Sebastian! Federico Jinkis <div class="gmail_extra"> <div class="gmail_quote">El 19 nov. 2016 07:22, "Sebastian Dröge-3 [via GStreamer-devel]" <<a href="/user/SendEmail.jtp?type=node&node=4680874&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>> escribió: <blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, 2016-11-16 at 11:38 -0800, fedejinkis wrote: > As you said, I checked the sequence number of the RTP packets and there are > not monotonically increasing in my mesh. In fact, some of them are the same, > but in many opportunities, the sequence number is an old one. That means packets are resent. rtpjitterbuffer would fix that part. > On the other hand, in my home network, the RTP packets are not monotonically > increasing either. The video stream is bad and although now is not a gray > screen, the video have about more than minute and a half of delay, the old > sequence numbers are much less frequent but the presence of the repeated > sequence number ones are equally than the in the mesh. Basically it looks like you have packet loss and/or other problems in your network then. To some degree rtpjitterbuffer can fix that, especially if you set up RTX (or FEC). Check in the rtpjitterbuffer logs what it complains about to see which parts it can't fix anymore by itself. > In what respect of SPS/PPS code data in the H264, I also tried to see them > with Wireshark (I do not know how to do it with some plugin of GStreamer, in > fact, I have had a look in gst-inspect but I did not realise what property > or cap must be set to it). I saw that for every 3 or 4 packets with > different sequence number, one with start bit and payload unit has been > sent. Ideally SPS/PPS are passed out of band via the SDP (or caps). Otherwise the payloader can also insert them in regular intervals into the stream, or the encoder. > So, the packets are arriving late, are not them? > How can I find a solution to this issue? There is a special command to > stream and receive in IPv6? Or is just that my network it is not properly to > this application? See above, I'd say your network has some problems. -- Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="nofollow" link="external" target="_blank">http://www.centricular.com</a> _______________________________________________ gstreamer-devel mailing list <a href="http:///user/SendEmail.jtp?type=node&node=4680781&i=0" rel="nofollow" link="external" target="_blank">[hidden email]</a> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="nofollow" link="external" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> <div class="m_-5311627000872587733small"> <img src="http://gstreamer-devel.966125.n4.nabble.com/images/icon_attachment.gif"> signature.asc (981 bytes) <a href="http://gstreamer-devel.966125.n4.nabble.com/attachment/4680781/0/signature.asc" rel="nofollow" link="external" target="_blank">Download Attachment</a></div> <hr noshade size="1" color="#cccccc"> <div style="color:#444;font:12px tahoma,geneva,helvetica,arial,sans-serif"> <div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div> <a href="http://gstreamer-devel.966125.n4.nabble.com/Problems-with-udpsrc-in-IPv6-tp4680432p4680781.html" target="_blank" rel="nofollow" link="external">http://gstreamer-devel.966125.n4.nabble.com/Problems-with-udpsrc-in-IPv6-tp4680432p4680781.html</a> </div> <div style="color:#666;font:11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em"> To unsubscribe from Problems with udpsrc in IPv6, <a href="" target="_blank" rel="nofollow" link="external">click here</a>. <a href="http://gstreamer-devel.966125.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" rel="nofollow" style="font:9px serif" target="_blank" link="external">NAML</a> </div></blockquote></div></div> <hr align="left" width="300" /> View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/Problems-with-udpsrc-in-IPv6-tp4680432p4680874.html">Re: Problems with udpsrc in IPv6</a> Sent from the <a href="http://gstreamer-devel.966125.n4.nabble.com/">GStreamer-devel mailing list archive</a> at Nabble.com.