<div dir="ltr"><div><div><div>Thank you for the suggestion. I will definitely look into it. I found a warning message buried in the GStreamer log file and googled it. Here is the best hit.<br><br><a href="http://gstreamer-devel.966125.n4.nabble.com/create-simple-pipeline-receive-udpsrc-rtp-stream-and-send-rtsp-td3328693.html">http://gstreamer-devel.966125.n4.nabble.com/create-simple-pipeline-receive-udpsrc-rtp-stream-and-send-rtsp-td3328693.html</a><br>
<br></div>That is my pipeline. This seems to be a well known problem. I don't understand what the root is but do have some guesses. Frankly, I think that the GStreamer folks should document this issue with the RTSP server so unsuspecting people don't wander into the bear trap, assuming that they don't want to (or can't?) fix it. This is causing some serious problems with the project I am working on.<br>
<br></div>I am testing an approach to specify the sprop property to the rtph264pay element. That has helped tremendously, though it still isn't working and I don't yet know why (last test was late last night). I am guessing that I may need to establish a probe to listen for the SPS & PPS headers on the incoming stream, capture them and then generate my pipeline with that property. I would like, though, to understand what is failing and why they can't be pulled from the incoming bitstream.<br>
<br></div>Chuck<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 2, 2013 at 4:14 AM, Federico Zamperini <span dir="ltr"><<a href="mailto:fzamperini@tiscali.it" target="_blank">fzamperini@tiscali.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not a solution, just a suggestion: use a gst-launch pipeline using a playbin (playbin2 on gstreamer 0.10) to play the stream.<br>
I once had a problem with UDP ports being blocked and while VLC gave up with no helpful messages, the gst-launch pipeline was smart enough to wait 5 seconds, declare that no UDP packets arrived in that interval and then switch to TCP (that is: asked the RTSP server to send RTP media packets on TCP rather than on UDP). This may not be your case, but gst-launch showed to be really smart and helpful.<br>
<br>
Federico<br>
<br>
Il 01/08/2013 18:08, Chuck Crisler ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
I am working with the GStreamer RTSP server simply trying to relay an<br>
RTP stream. Here is my desired pipeline:<br>
<br>
udpsrc port=%d name=RTPSrc !<br>
application/x-rtp,media=video,<u></u>payload=96,clock-rate=90000,<u></u>encoding-name=H264"<br>
" ! rtph264depay byte-stream=true name=RTPDePay ! video/x-h264<br>
! h264parse ! rtph264pay name=pay0 pt=96 )<br>
<br>
This pipeline doesn't work in this context. This string is actually used<br>
to generate the real pipeline which has the udpsrc port set. I have<br>
tested this pipeline in a script where I added a udpsink to send the RTP<br>
to another system to render. That worked fine.<br>
<br>
This pipeline takes about 5 seconds to reach the prerolled state, though<br>
it is a live pipeline. At that point it seems that VLC disconnects the<br>
TCP connection (I don't know why but wireshark showed a TCP FIN). The<br>
video source should be feeding an IFrame about once per second. The<br>
SPS/PPS headers are re-transmitted every 3-5 seconds.<br>
<br>
I did get a message that I don't understand.<br>
<br>
(<unknown>:10559): WARNING **: ignoring stream 0 without media type<br>
<br>
I substituted a test pipeline based on videotestsrc feeding the x264enc<br>
to rtph264pay and that (sort of) worked. By 'sort of' I did get a couple<br>
of frames displayed on VLC but there weren't many. It seemed like the<br>
stream wasn't working well, which is confusing but a secondary issue at<br>
the moment.<br>
<br>
Would anyone please care to comment on this issue? I am running out of<br>
ideas.<br>
<br>
Thank you,<br>
Chuck Crisler<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/gstreamer-<u></u>devel</a><br>
<br>
<br>
<br>
Nessun virus nel messaggio.<br>
Controllato da AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a> <<a href="http://www.avg.com" target="_blank">http://www.avg.com</a>><br>
Versione: 2013.0.3392 / Database dei virus: 3209/6542 - Data di<br>
rilascio: 01/08/2013<br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/gstreamer-<u></u>devel</a><br>
</blockquote></div><br></div>