Problems with udpsrc in IPv6
fedejinkis
fedejinkis at gmail.com
Sat Nov 12 18:33:51 UTC 2016
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!
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Problems-with-udpsrc-in-IPv6-tp4680432p4680655.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
More information about the gstreamer-devel
mailing list