> I have a streaming source that already provides me with a h264 RTP stream and
> would like to use live555 just as a RTSP server.
> I require neither RTP packetization nor RTCP generation.
>
> I found your answer to this question:
> http://lists.live555.com/pipermail/live-devel/2014-September/018672.html
> and follow instructions.
>
> Everything works fine expect I don't receive any video. In vlc I get timeout
> after 10 sec.
> Can you check attached openRTSP log and source code if everything is ok?
>
> h264 stream is unicast to IP 172.16.245.114 port 5283
> RTSP server: 192.168.221.109 port 8554
> Stream url: rtsp://192.168.221.109/video
What you’re trying to do is rather unusual - but it should be possible, I
think. Note, however, that because your existing RTP stream is unicast, you
will be able to receive it only on a single (unicast) address and port, so I
assume that you were running your RTSP client application (first VLC; then
openRTSP) on the host 172.16.245.114.
Are you *sure* that your existing H.264/RTP stream is being sent to IP address
172.16.245.114, port 5283, with RTP payload format code 96? It’s unusual for
the RTP port number to be odd-numbered. That may be the cause of your problem;
the client RTSP/RTP receiving code is probably getting confused by the odd port
number. If it’s really the case that your RTP stream is using this odd port
number, then you can compensate for this in your server code by using just a
*single* ‘groupsock’ object - with port number 5283 - for both the “RTPSink”
*and* “RTCPInstance” objects.
I.e., in your code, do:
m_rtpAndRTCPGroupsock = new Groupsock(*m_UsageEnviroment,
m_destinationAddress, 5283, 255);
…
H264VideoRTPSink* m_VideoSink =
H264VideoRTPSink::createNew(*m_UsageEnviroment, m_rtpAndRTCPGroupsock,
rtpPayloadFormat, sps, spsSize, pps, ppsSize);
...
m_RTCP = RTCPInstance::createNew(*m_UsageEnviroment,
m_rtpAndRTCPGroupsock, estimatedSessionBandwidth, CNAME, m_VideoSink, NULL,
False);
// Note: the last parameter should be “False”, not “True”, because this
is not SSM multicast. Though it probably doesn’t matter in this case.
This will tell the RTSP server to include the line
a=rtcp-mux
in the stream’s SDP description (i.e., returned in response to the RTSP
“DESCRIBE” command), which will in turn tell the RTSP client to expect the RTP
packets to use the odd port number 5283 (rather than the even port number 5282).
Finally, I suggest that you first use “testRTSPClient” - rather than “openRTSP”
- as your initial RTSP client application. (Once again, of course, you will
need to run this on the host 172.16.245.114.) The advantage of running
“testRTSPClient” is that it will tell you if/when it receives each H.264 NAL
unit, which in turn will tell you if it’s receiving the RTP stream that it
expects. (Alternatively, you can run “openRTSP” with the “-n” option, to tell
it to announce when it receives the first valid RTP data.)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
