RTSP Server problem

[Federico Zamperini]

As far as my experience is concerned, I knew that while a RTSP stream 
bears information on the underlying RTP stream (in the sdp fields), a 
bare RTP stream doesn't (at least not explicitly)
In a RTP sender I made I had to hardcode the caps on the receiver side, 
the same happened to the guy who posted the last mail message in the 
thread you linked.

A more flexible approach, though, would not be to hard code the caps on 
the receiver side but instead to establish a reliable connection (for 
example a TCP connection) aside form the RTP stream to communicate the 
source parameters.
And that's exactly what RTSP does.

Federico


Il 02/08/2013 15:36, Chuck Crisler ha scritto:
> 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.
>
> http://gstreamer-devel.966125.n4.nabble.com/create-simple-pipeline-receive-udpsrc-rtp-stream-and-send-rtsp-td3328693.html
>
> 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.
>
> 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.
>
> Chuck
>
>
> On Fri, Aug 2, 2013 at 4:14 AM, Federico Zamperini
> <fzamperini at tiscali.it <mailto:fzamperini at tiscali.it>> wrote:
>
>     Not a solution, just a suggestion: use a gst-launch pipeline using a
>     playbin (playbin2 on gstreamer 0.10) to play the stream.
>     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.
>
>     Federico
>
>     Il 01/08/2013 18:08, Chuck Crisler ha scritto:
>
>         I am working with the GStreamer RTSP server simply trying to
>         relay an
>         RTP stream. Here is my desired pipeline:
>
>            udpsrc port=%d name=RTPSrc !
>         application/x-rtp,media=video,__payload=96,clock-rate=90000,__encoding-name=H264"
>                   " ! rtph264depay byte-stream=true name=RTPDePay !
>         video/x-h264
>         ! h264parse ! rtph264pay name=pay0 pt=96 )
>
>         This pipeline doesn't work in this context. This string is
>         actually used
>         to generate the real pipeline which has the udpsrc port set. I have
>         tested this pipeline in a script where I added a udpsink to send
>         the RTP
>         to another system to render. That worked fine.
>
>         This pipeline takes about 5 seconds to reach the prerolled
>         state, though
>         it is a live pipeline. At that point it seems that VLC
>         disconnects the
>         TCP connection (I don't know why but wireshark showed a TCP
>         FIN). The
>         video source should be feeding an IFrame about once per second. The
>         SPS/PPS headers are re-transmitted every 3-5 seconds.
>
>         I did get a message that I don't understand.
>
>         (<unknown>:10559): WARNING **: ignoring stream 0 without media type
>
>         I substituted a test pipeline based on videotestsrc feeding the
>         x264enc
>         to rtph264pay and that (sort of) worked. By 'sort of' I did get
>         a couple
>         of frames displayed on VLC but there weren't many. It seemed
>         like the
>         stream wasn't working well, which is confusing but a secondary
>         issue at
>         the moment.
>
>         Would anyone please care to comment on this issue? I am running
>         out of
>         ideas.
>
>         Thank you,
>         Chuck Crisler