Problems with udpsrc in IPv6

[fedejinkis]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Thu, 2016-11-03 at 17:09 -0300, Federico Jinkis wrote:

>
> B''H
> Hello everyone, I'm new in this mailing list. 
> I am an student of Computer Engineering in UNS, Bahia Blanca,
> Argentina and I have many problems with gstreamer. I do not have
> anything else to do, I am keeping without options.
> Basically I want to stream in live from my raspberry to my PC through
> the IPv6 link-site direction. The server (my RPi3) sends the packets
> and there are arriving (because when I check with tcpdump in my PC I
> can see them) but my gstreamer client do not reproduces them, it is
> like nothing be happen. I use the following commands:
>
> In RPi3:
> > raspivid -n -w 720 -h 480 -b 4500000 -fps 30 -vf -hf -t 0 -o - |
> > \gst-launch-1.0 -v fdsrc !  h264parse ! rtph264pay config-
> > interval=10 pt=96 ! \udpsink host=fe80::14ed:a3ff:fe1e:80f6%bat0
> > port=9000
>
> In Fedora 24 (my PC)
> > gst-launch-1.0 -v udpsrc port=9000 caps='application/x-rtp,
> > media=(string)video, clock-rate=(int)90000, encoding-
> > name=(string)H264' ! \rtph264depay ! avdec_h264 ! videoconvert !
> > autovideosink sync=false
>
> I have tried adding "multicast-group=::1" (deprecated) and use the
> attribute "address" that is specified in gst-inspect, but although
> other threads have obteined the solution, in my case there is no
> results... I really need it, because, later, I would like to stream
> with a multicast address (something that I do not know how to do),
> what I suppose there is more complex.

Use the address property on udpsrc to give the correct IP (and possibly
multicast-iface if this is multicast). Then check with something like
  gst-launch-1.0 -v \
    udpsrc ... ! fakesink silent=false
if packets are actually arriving at udpsrc. If not, settings have to be
changed on it accordingly (especially if packets arrive in wireshark).


For the sender, you might want to use rpicamsrc instead of such a duct-
tape solution over fdsrc: https://github.com/thaytan/gst-rpicamsrc

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[fedejinkis]

Excuse me for my delay, I was studying for some exams.
I have proved with address attribute setted in multicast and fakesink silent in false. The packets are arriving too, but there still are not showing in gst-launch. Perhaps, it is important to say that when I use it with IPv4, there are not problems, although, I need it using IPv6. The messages of fakesink was like:

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (1400 bytes, dts: 0:00:00.178135703, pts: 0:00:00.178135703, duration: none, offset: -1, offset_end: -1, flags: 00004000 tag-memory ) 0x7f19c00163d0

I think that looks good, I believe that the problem is not there.

I am using the following command now (the IPv6 is dynamic, so do not pay attention If it is not matching with the old one command):

gst-launch-1.0 -v udpsrc address=ff02::1:ffbb:4e7c port=9000 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! \rtph264depay ! avdec_h264 ! videoconvert ! autovideosink sync=false


In the other hand, I am actually using that plug-in of Raspberry Camera, I did not say it just to avoid add more complexity to my question. But indeed, this is my command in the server:

gst-launch-1.0 rpicamsrc vflip=true hflip=true bitrate=4500000 ! video/x-h264,width=720,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=10 pt=96 ! \udpsink host=ff02::1:ffbb:4e7c%bat0 port=9000


Thanks for everything and I will appreciate your help very much!!

[Sebastian Dröge-3]

On Thu, 2016-11-10 at 09:05 -0800, fedejinkis wrote:

> Excuse me for my delay, I was studying for some exams. 
> I have proved with address attribute setted in multicast and fakesink silent
> in false. The packets are arriving too, but there still are not showing in
> gst-launch. Perhaps, it is important to say that when I use it with IPv4,
> there are not problems, although, I need it using IPv6. The messages of
> fakesink was like:
>
> //GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain  
> ******* (fakesink0:sink) (1400 bytes, dts: 0:00:00.178135703, pts:
> 0:00:00.178135703, duration: none, offset: -1, offset_end: -1, flags:
> 00004000 tag-memory ) 0x7f19c00163d0/

So you're saying that an "udpsrc ! fakesink" pipeline receives the
packets? In that case the problem will be in the following elements.
Check part by part where things start to get lost, and then debug that
part by debug logs and looking into the code.
Or you mean it only worked with IPv4 like that?

In that case please look at the udpsrc code and check if it does
anything wrong in there. Debug with the fakesink pipeline, check the
debug logs if it uses the correct addresses and ports everywhere, check
if it sets up the socket correctly.


Also note https://bugzilla.gnome.org/show_bug.cgi?id=764679 in case
you're using an older version than 1.8.2.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[fedejinkis]

Thanks Sebastian for your quick answer.

Yes, you are correct, what I was saying was that the packets have been received by the udpsrc ! fakesink. So, as you told me that the problem could be in another element, my first step was just wait a little longer to see what will happen. The result was that, in 10 minutes aprox, the video started with a gray screen (never be better) and the message of Redistribute latency.... Here is the entire message:


$ gst-launch-1.0 -v udpsrc address=ff02::1:ff4a:6c9f port=9000 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! \rtph264depay ! avdec_h264 ! videoconvert ! autovideosink sync=false

Setting pipeline to PAUSED ...

Pipeline is live and does not need PREROLL ...

/GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps = "application/x-rtp\,\ media\=\(string\)video\,\ clock-rate\=\(int\)90000\,\ encoding-name\=\(string\)H264"

Setting pipeline to PLAYING ...

New clock: GstSystemClock

/GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps = "application/x-rtp\,\ media\=\(string\)video\,\ clock-rate\=\(int\)90000\,\ encoding-name\=\(string\)H264"


[Later of ten minutes when the video window started...]


/GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps = "video/x-h264\,\ stream-format\=\(string\)avc\,\ alignment\=\(string\)au\,\ codec_data\=\(buffer\)01428028ffe1000d2742802895a02d0f680789135001000528ce025c80\,\ level\=\(string\)4\,\ profile\=\(string\)baseline"

/GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:sink: caps = "video/x-h264\,\ stream-format\=\(string\)avc\,\ alignment\=\(string\)au\,\ codec_data\=\(buffer\)01428028ffe1000d2742802895a02d0f680789135001000528ce025c80\,\ level\=\(string\)4\,\ profile\=\(string\)baseline"

/GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)720\,\ height\=\(int\)480\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)25/1"

/GstPipeline:pipeline0/GstVideoConvert:videoconvert0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)720\,\ height\=\(int\)480\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)25/1"

/GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)720\,\ height\=\(int\)480\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)25/1"

/GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage.GstPad:sink: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)720\,\ height\=\(int\)480\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)25/1"

/GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0.GstGhostPad:sink: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)720\,\ height\=\(int\)480\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)25/1"

/GstPipeline:pipeline0/GstVideoConvert:videoconvert0.GstPad:sink: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)720\,\ height\=\(int\)480\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)25/1"

Redistribute latency...


So, although I do not understand anything of the messages displayed, I think that the problem could be the rate of transmission, could not it? Knowing that my server streams with this command:

gst-launch-1.0 rpicamsrc vflip=true hflip=true bitrate=4500000 ! video/x-h264,width=720,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=10 pt=96 ! \udpsink host=SOME_ADDR port=9000

I am seeing that the codecs are changing for some reason from h264 to mpeg2 and the framerate from 30/1 to 25/1.
I really do not know what to do, I read about the pipeline composition, the pads src and sink, differents details of some plugins, but as more I study more complex is everything.

Do you have any idea of what is going on? How can I use the debug option? I tried with fakesink and progressreport element, but it depends if the element before are expecting source or are returning to a sink element.

Finally, I verified the version of my GStreamer and it is 1.8.3. When I said that with IPv4 all of this were not happening, I referred that with the same commands but, just changing the host property of udpsink in the server to a IPv4, all were working perfect.

Thanks in advance! I really appreciate your help!

[Sebastian Dröge-3]

On Sat, 2016-11-12 at 10:33 -0800, fedejinkis wrote:

> Thanks Sebastian for your quick answer. 
>
> Yes, you are correct, what I was saying was that the packets have
> been
> received by the udpsrc ! fakesink. So, as you told me that the
> problem could
> be in another element, my first step was just wait a little longer to
> see
> what will happen. The result was that, in 10 minutes aprox, the video
> started with a gray screen (never be better) and the message of
> /*Redistribute latency...*/. Here is the entire message:
> [...]

Please check if a) there are packets getting lost (RTP has
monotonically increasing sequence numbers), e.g. with wireshark and b)
check if the H264 codec data (SPS/PPS) is sent regularly. Decoders
won't work properly if they don't have this.

This can also be provided by the caps (or inside an SDP), in the
sprops-parameter-sets for the depayloader. The payloader is also
putting this into its caps.


Basically check if you get a valid and complete stream. If so, please
check where output stops to come (e.g. if the decoder gets input but
does not output anything), and then we can continue looking.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[fedejinkis]

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.

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.

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.

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?

I add the Wireshark screenshot.
Thanks so much Sebeastian, I hope you can help me.

[Sebastian Dröge-3]

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 · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[fedejinkis]

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

El 19 nov. 2016 07:22, "Sebastian Dröge-3 [via GStreamer-devel]" <[hidden email]> escribió:

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 · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (981 bytes) Download Attachment

---

If you reply to this email, your message will be added to the discussion below:

http://gstreamer-devel.966125.n4.nabble.com/Problems-with-udpsrc-in-IPv6-tp4680432p4680781.html

To unsubscribe from Problems with udpsrc in IPv6, click here.
NAML

[Sebastian Dröge-3]

On Thu, 2016-11-24 at 23:13 -0800, fedejinkis wrote:
> 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.

no-lost=true only prevents rtpjitterbuffer from reporting lost events.
It still does the same work.

What problem persists though?

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

IPv6 generally works just fine in GStreamer. You really need to debug
in more detail here what happens, my best guess at this point is that
your network behaves different with IPv6 or there is some kind of
misconfiguration.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel