Hi I am sure that h264/RTP stream is being sent to address 172.16.245.114 port 5283. If client must be on same device then this is not right solution for me. I have camera on embedded device that is streaming to that address. I am trying to develop RTSPServer on embedded device so client can connect to it and receive stream.
I need to start client (for example vlc) on my Linux PC and connect to RTSP server on embedded device by rtsp url. Is that possible with this approach? It looks far easiest to implement so I first try it. So far I compiled live555 for arm Linux and successfully stream test.264 file from embedded device to my Linux PC using H264VideoFileServerMediaSubsession. After that I tried to change source of h264 from file to camera stream. I found this answer http://lists.live555.com/pipermail/live-devel/2014-September/018672.html and try to implement it but maybe this is not best approach for me? Second idea is to subclass RTSPServer, ignore ServerMediaSession and reiplement handleCmd*. So when I recive client connection I do prerouting udp packets from camera to client IP and port and send that address in SDP. But I will need more advices from you for that approach. Is that better approach or you have othed idea? Best regards -----Original Message----- From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: 30. desember 2015 16:52 To: LIVE555 Streaming Media - development & use <live-de...@ns.live555.com> Subject: Re: [Live-devel] RTSPServer with PassiveServerMediaSubsession from live camera > 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.ht > ml > 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 DISCLAIMER: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
