From ashvyrkin at gosniias.ru Mon Jun 3 21:10:17 2013 From: ashvyrkin at gosniias.ru (=?UTF-8?B?0JDQvdC00YDQtdC5?=) Date: Tue, 04 Jun 2013 08:10:17 +0400 Subject: [Live-devel] MilestoneXProtect playing problem Message-ID: <51AD68A9.3050404@gosniias.ru> Hi, Ross. Thank you for your library. I'm developing a server application, which virtulnogo ONVIF camera. I implemented the transmission of live video in H264, MPEG4 and JPEG. In the architecture of the application code I used testOnDemandRTSPServer. As I used the FFMPEG encoder. If you use to view the RTSP stream VLC or your client initially as a binder LIVE555 + FFMPEG, playing without any problems. But for a number of reasons emerged neobhodimot support with the application MilestoneXProtect. As the type of device I used ONVIFConformanceDevice. The problem is that the built RTSP client starts playing the stream, but about every 45 seconds, the client loses its connection and reconnection happens to my server. Help to understand the reason for the incompatibility. Sorry for bad english... From warren at etr-usa.com Tue Jun 4 17:56:01 2013 From: warren at etr-usa.com (Warren Young) Date: Tue, 04 Jun 2013 18:56:01 -0600 Subject: [Live-devel] Why does groupsock bind to 0.0.0.0 for streamers? Message-ID: <51AE8CA1.5070900@etr-usa.com> If you say $ strace -e bind ./testMPEG2TransportStreamer you find that it calls bind() twice, once for 0.0.0.0:1234, and another time for the "find my IP" hack. Ultimately, I don't see why it needs to call bind() at all in this program since a UDP sender is just tossing packets out onto the network. It's not receiving anything. (Yes, I saw the "Windoze" case mentioned in the nearby comment. Separate issue. We're on Linux.) This causes a problem for us because we have another program -- not based on Live555 -- which is simultaneously trying to receive packets from a different IP on the same port number, and it gets a bind() failure (errno = EADDRINUSE) because the Live555 program has effectively claimed total ownership of that port number on all interfaces by asking for 0.0.0.0. I've tried running two instances of testMPEG2TransportStreamer on different IPs, and apparently our network stack (Linux 2.6.18) will let two programs bind() to 0.0.0.0:1234, but it won't let another program bind to, say, 239.255.42.44:1234 at the same time. We made a one-line change to Live555 (see attached patch) and it fixes the symptom for us. It seems like a reasonable change to me, but I'm not sure it isn't some kind of overreach. We could instead fix this by using different port numbers *and* different IPs for our senders and receivers. (We tried it, and it worked.) We don't want to do that purely because separating senders and receivers by putting them on different multicast addresses should be enough. That make a different 5-tuple, so we should be able to keep the same port number. -------------- next part -------------- A non-text attachment was scrubbed... Name: live555-groupsock-bind.patch Type: text/x-patch Size: 351 bytes Desc: not available URL: From finlayson at live555.com Tue Jun 4 18:08:04 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Jun 2013 18:08:04 -0700 Subject: [Live-devel] Why does groupsock bind to 0.0.0.0 for streamers? In-Reply-To: <51AE8CA1.5070900@etr-usa.com> References: <51AE8CA1.5070900@etr-usa.com> Message-ID: > Ultimately, I don't see why it needs to call bind() at all in this program since a UDP sender is just tossing packets out onto the network. It's not receiving anything. Yes it is. It's also receiving RTCP "RR" reports from receiving clients. > We made a one-line change to Live555 (see attached patch) and it fixes the symptom for us. It seems like a reasonable change to me, but I'm not sure it isn't some kind of overreach. No, I'm reluctant to make any changes to the 'groupsock' code, because (1) these always seem to unintended side effects (breaking some people's applications, and/or Windoze code somewhere), and (2) the plan is for the 'groupsock' library to be complete replaced at some point in the future: http://live555.com/funded-projects/live555-ipv6.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Tue Jun 4 19:34:58 2013 From: warren at etr-usa.com (Warren Young) Date: Tue, 04 Jun 2013 20:34:58 -0600 Subject: [Live-devel] Why does groupsock bind to 0.0.0.0 for streamers? In-Reply-To: References: <51AE8CA1.5070900@etr-usa.com> Message-ID: <51AEA3D2.1040309@etr-usa.com> On 6/4/2013 19:08, Ross Finlayson wrote: >> Ultimately, I don't see why it needs to call bind() at all in this >> program since a UDP sender is just tossing packets out onto the >> network. It's not receiving anything. > > Yes it is. It's also receiving RTCP "RR" reports from receiving clients. Okay, but does it really need to bind to 0.0.0.0 instead of to 239.255.42.42? Also, the bind() still occurs if you change the example to send using raw UDP. From ashvyrkin at gosniias.ru Wed Jun 5 21:25:15 2013 From: ashvyrkin at gosniias.ru (=?UTF-8?B?0JDQvdC00YDQtdC5?=) Date: Thu, 06 Jun 2013 08:25:15 +0400 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <51AD68A9.3050404@gosniias.ru> References: <51AD68A9.3050404@gosniias.ru> Message-ID: <51B00F2B.10108@gosniias.ru> 04.06.2013 8:10, ?????? ?????: > Hi, Ross. Thank you for your library. I'm developing a server > application, which virtulnogo ONVIF camera. I implemented the > transmission of live video in H264, MPEG4 and JPEG. In the > architecture of the application code I used testOnDemandRTSPServer. As > I used the FFMPEG encoder. If you use to view the RTSP stream VLC or > your client initially as a binder LIVE555 + FFMPEG, playing without > any problems. But for a number of reasons emerged neobhodimot support > with the application MilestoneXProtect. As the type of device I used > ONVIFConformanceDevice. The problem is that the built RTSP client > starts playing the stream, but about every 45 seconds, the client > loses its connection and reconnection happens to my server. Help to > understand the reason for the incompatibility. > Sorry for bad english... I can provide the additional output from the console. Client Milestone constantly sending requests to my server, and soon breaks the connection and then reconnects. Help solve the problem User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "7", Content-Length 0, with 0 bytes following the mes sage. sending response: RTSP/1.0 200 OK CSeq: 7 Date: Thu, Jun 06 2013 04:15:49 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 115 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 8 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "8", Content-Length 0, with 0 bytes following the mes sage. sending response: RTSP/1.0 200 OK CSeq: 8 Date: Thu, Jun 06 2013 04:15:54 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 115 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 9 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "9", Content-Length 0, with 0 bytes following the mes sage. sending response: RTSP/1.0 200 OK CSeq: 9 Date: Thu, Jun 06 2013 04:15:59 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 116 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 10 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "10", Content-Length 0, with 0 bytes following the me ssage. sending response: RTSP/1.0 200 OK CSeq: 10 Date: Thu, Jun 06 2013 04:16:04 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 116 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 11 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "11", Content-Length 0, with 0 bytes following the me ssage. sending response: RTSP/1.0 200 OK CSeq: 11 Date: Thu, Jun 06 2013 04:16:09 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 116 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 12 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "12", Content-Length 0, with 0 bytes following the me ssage. sending response: RTSP/1.0 200 OK CSeq: 12 Date: Thu, Jun 06 2013 04:16:14 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 116 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 13 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "13", Content-Length 0, with 0 bytes following the me ssage. sending response: RTSP/1.0 200 OK CSeq: 13 Date: Thu, Jun 06 2013 04:16:19 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 116 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 14 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "14", Content-Length 0, with 0 bytes following the me ssage. sending response: RTSP/1.0 200 OK CSeq: 14 Date: Thu, Jun 06 2013 04:16:24 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 116 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 15 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "15", Content-Length 0, with 0 bytes following the me ssage. sending response: RTSP/1.0 200 OK CSeq: 15 Date: Thu, Jun 06 2013 04:16:29 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSP client session (id "3944E412", stream name "media0") has timed out (due to inactivity) RTSPClientConnection[060959F8]::handleRequestBytes() read 116 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 16 Session: 3944E412 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "16", Content-Length 0, with 0 bytes following the me ssage. sending response: RTSP/1.0 200 OK CSeq: 16 Date: Thu, Jun 06 2013 04:16:34 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 123 new bytes:TEARDOWN rtsp://192.168.33.77:13200/media0/track1 RTSP/1.0 Session: 3944E412 CSeq: 17 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix " media0", urlSuffix "track1", CSeq "17", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 454 Session Not Found CSeq: 17 Date: Thu, Jun 06 2013 04:16:38 GMT RTSPClientConnection[060959F8]::handleRequestBytes() read -1 new bytes (of 10000 ); terminating connection! accept()ed connection from 192.168.33.77 RTSPClientConnection[060959F8]::handleRequestBytes() read 140 new bytes:DESCRIBE rtsp://192.168.33.77:13200/media0 RTSP/1.0 CSeq: 1 Accept: application/sdp User-Agent: CmRtspClient 86951 Bandwidth: 384000 parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix " ", urlSuffix "media0", CSeq "1", Content-Length 0, with 0 bytes following the me ssage. sending response: RTSP/1.0 200 OK CSeq: 1 Date: Thu, Jun 06 2013 04:16:43 GMT Content-Base: rtsp://192.168.33.77:13200/media0/ Content-Type: application/sdp Content-Length: 370 v=0 o=- 1370492094745333 1 IN IP4 192.168.33.77 s=Session streamed by "RTSPMediaServer" i=media0 t=0 0 a=tool:LIVE555 Streaming Media v2013.05.30 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "RTSPMediaServer" a=x-qt-text-inf:media0 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=control:track1 RTSPClientConnection[060959F8]::handleRequestBytes() read 120 new bytes:SETUP rt sp://192.168.33.77:13200/media0/track1 RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=24906-24907 parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "med ia0", urlSuffix "track1", CSeq "2", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 2 Date: Thu, Jun 06 2013 04:16:43 GMT Transport: RTP/AVP;unicast;destination=192.168.33.77;source=192.168.33.77;client _port=24906-24907;server_port=6970-6971 Session: FFEA9879 RTSPClientConnection[060959F8]::handleRequestBytes() read 99 new bytes:PLAY rtsp ://192.168.33.77:13200/media0/ RTSP/1.0 Session: FFEA9879 CSeq: 3 Range: npt=0.000- parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "medi a0", urlSuffix "", CSeq "3", Content-Length 0, with 0 bytes following the messag e. sending response: RTSP/1.0 200 OK CSeq: 3 Date: Thu, Jun 06 2013 04:16:43 GMT Range: npt=0.000- Session: FFEA9879 RTP-Info: url=rtsp://192.168.33.77:13200/media0/track1;seq=28630;rtptime=1504623 387 RTSPClientConnection[060959F8]::handleRequestBytes() read 115 new bytes:OPTIONS rtsp://192.168.33.77:13200/media0/ RTSP/1.0 CSeq: 4 Session: FFEA9879 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "m edia0", urlSuffix "", CSeq "4", Content-Length 0, with 0 bytes following the mes sage. sending response: RTSP/1.0 200 OK CSeq: 4 Date: Thu, Jun 06 2013 04:16:48 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientConnection[060959F8]::handleRequestBytes() read 122 new bytes:TEARDOWN rtsp://192.168.33.77:13200/media0/track1 RTSP/1.0 Session: FFEA9879 CSeq: 5 User-Agent: CmRtspClient 86951 parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix " media0", urlSuffix "track1", CSeq "5", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 5 Date: Thu, Jun 06 2013 04:16:49 GMT RTSPClientConnection[060959F8]::handleRequestBytes() read -1 new bytes (of 10000 ); terminating connection! From warren at etr-usa.com Thu Jun 6 09:31:11 2013 From: warren at etr-usa.com (Warren Young) Date: Thu, 06 Jun 2013 10:31:11 -0600 Subject: [Live-devel] Debug mode enabled in 2013.05.30 RTSPServer.cpp Message-ID: <51B0B94F.7050606@etr-usa.com> Ross, it looks like you accidentally shipped RTSPServer.cpp with a #define DEBUG line in it. From finlayson at live555.com Thu Jun 6 11:39:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Jun 2013 11:39:09 -0700 Subject: [Live-devel] Debug mode enabled in 2013.05.30 RTSPServer.cpp In-Reply-To: <51B0B94F.7050606@etr-usa.com> References: <51B0B94F.7050606@etr-usa.com> Message-ID: <974DAB19-701D-44EF-AA4B-A4C037735C39@live555.com> > Ross, it looks like you accidentally shipped RTSPServer.cpp with a #define DEBUG line in it. Oops, you're right. Fixed now. Thanks for letting me know. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 7 01:31:17 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Jun 2013 01:31:17 -0700 Subject: [Live-devel] Bug analyze_sei_data() & Session timeout questions In-Reply-To: References: Message-ID: > RtspServer: An OPTIONS with a proper "Session: XYZ" does not seem to trigger RTSPClientSession::noteLiveness(). > Is that a wanted behavior ? Yes, because the "OPTIONS" command applies to the entire server, and is not specific to a particular session. (In other words, a "Session:" header in an "OPTIONS" command is ignored.) > If yes, apart from sending RTCP No, "apart from sending RTCP" should not apply here, because RTCP is a mandatory part of the RTP/RTCP protocol. A RTSP/RTP client should also implement RTCP, and send periodic RTCP "RR" ("Reception Report") packets, which the server will recognize as indicating that the client is still alive. (Note that our RTSP client implementation automatically includes RTCP.) Having said that, I should note that our server will also recognize any session-specific command (including "GET_PARAMETER") as indicating client liveness. > would it be possible to change the many [...] > to use > > "Session: %08X;timeout=%u\r\n\r\n", ..., fOurSessionId, fReclamationTestSeconds); Of course it would be 'possible', but I'm probably not going to do it, because (1) it's not required, and (2) it is not necessary, if clients send RTCP "RR" reports, as they are supposed to. (I'm disinclined to implement a feature that might encourage RTSP client developers (not using our libraries) to not implement RTCP.) > Bug: > In following code, if "if (NumBytesInNALunit > maxSize) return;" occurs, 'nalUnitCopySize' is not set to 0, 'seiSize' is unset/random, and it will most likely crash in the while loop. > Solution : > 1: Put 'nalUnitCopySize = 0;' before the return in H264VideoStreamParser::removeEmulationBytes > 2: unsigned seiSize = 0; Yes, that's a bug, albeit one that is unlikely to ever get triggered, because no SPS NAL unit should ever be larger than "SPS_MAX_SIZE" (and ditto for SEL NAL units and "SEI_MAX_SIZE"). Nonetheless, your suggested fix will be included in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at isdcam.com Fri Jun 7 08:48:02 2013 From: jim at isdcam.com (Jim VanVorst) Date: Fri, 7 Jun 2013 08:48:02 -0700 Subject: [Live-devel] Streaming faster than real time Message-ID: When streaming RTP from a file (say video.h264) the video streams to the network at the real time rate, I assume by parsing the sps/pps info and throttling the network writes to that frame rate. Is there a way to stream out at wire speed (or some scale) instead? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xieyongda at gmail.com Sat Jun 1 00:52:47 2013 From: xieyongda at gmail.com (=?GB2312?B?0LvTwLTv?=) Date: Sat, 1 Jun 2013 15:52:47 +0800 Subject: [Live-devel] Does it may cause crash? Message-ID: I'm a newbee, and nice to see you all. at RTPInterface.cpp line 354 delete fSubChannelHashTable; fSubChannelHashTable = NULL;// is it necessary? -- by:crazyevent -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 7 14:14:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Jun 2013 14:14:09 -0700 Subject: [Live-devel] testOnDemandRTSPServer Problem In-Reply-To: References: Message-ID: <902069CE-5567-4B67-AA2A-F07CA0991E2C@live555.com> > Hi, I'm having a problem getting the testprog RTSP Server to actually show a video file. I encoded the video file myself so it should be the correct format (MPEG4 H.264 Baseline AVC). Is this a H.264 Video *Elementary Stream* file - i.e., with video only, and *not* in a MPEG-4 file format? If so, then our server should be able to stream the file - but only if you give it a filename with the ".264" filename extension. The SDP output that you posted shows that the server thought that the video was "MP4V-ES", which meant that you must have given your filename a ".m4e" filename extension. This is *incorrect* if your video is H.264; you should use a ".264" filename extension instead. (Note also that our server cannot currently stream from a 'mp4' format file - only from (H.264 or MPEG-4) Elementary Stream files.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 7 21:39:12 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Jun 2013 21:39:12 -0700 Subject: [Live-devel] User-Agent Header In-Reply-To: References: Message-ID: > How to add user agent option that allows to set the User-Agent > header in openRTSP on the command line? The "RTSPClient" class has a member function: void setUserAgentString(char const* userAgentName); that any RTSP client application can use to set the RTSP "User-Agent:" header. (It's not a command-line option to "openRTSP" though; you would need to program that yourself.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Tue Jun 4 19:29:17 2013 From: kingaceck at 163.com (kingaceck) Date: Wed, 5 Jun 2013 10:29:17 +0800 Subject: [Live-devel] multicast port of client Message-ID: <201306051029163753850@163.com> Hi Ross I open two clients(using vlc) at the same host connecting to the same multicast source of live555 and I found that these two clients use the same port of rtp and rtcp : multicast client 1(using vlc): audio rtp port:30000 audio rtcp port:30001 video rtp port:30002 video rtcp port:30003 multicast client 2(using vlc): audio rtp port:30000 audio rtcp port:30001 video rtp port:30002 video rtcp port:30003 I want these two clients at the same host use different port (like unicast),how can I to do? I found the difference of SETUP response between multicast and unicast . the unicast's SETUP response like this: Transport: RTP/AVP;unicast;destination=129.1.5.155;source=129.1.5.156;client_port=1712-1713;server_port=6972-6973 the multicast's SETUP response like this: Transport: RTP/AVP;multicast;destination=229.1.1.1;source=129.1.5.156;port=30002-30003;ttl=255 Can I modify the multicast's SETUP reponse to define the client port like unicast's SETUP response? I want these two clients at the same host use different port (like unicast),how can I to do? Thank you very much. 2013-06-05 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From cohenguy1 at yahoo.com Wed Jun 5 10:41:52 2013 From: cohenguy1 at yahoo.com (Guy Cohen) Date: Wed, 5 Jun 2013 10:41:52 -0700 (PDT) Subject: [Live-devel] Streaming H.264 avc Message-ID: <1370454112.21030.YahooMailNeo@web125905.mail.ne1.yahoo.com> Hi I wanted to know if the live supports streaming of H.264/MPEG4 AVC (part 10) (h264). I ran the testOnDemandRTSPServer, but when I stream the h.264 movie and play it with vlc, the image is corrupted. The format of the video is mpg. I don't know where I went wrong... Thanks, Guy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 9 02:20:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Jun 2013 02:20:43 -0700 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <51B00F2B.10108@gosniias.ru> References: <51AD68A9.3050404@gosniias.ru> <51B00F2B.10108@gosniias.ru> Message-ID: >> If you use to view the RTSP stream VLC or your client initially as a binder LIVE555 + FFMPEG, playing without any problems. But for a number of reasons emerged neobhodimot support with the application MilestoneXProtect. As the type of device I used ONVIFConformanceDevice. The problem is that the built RTSP client starts playing the stream, but about every 45 seconds, the client loses its connection and reconnection happens to my server. Help to understand the reason for the incompatibility. Because your RTSP client application does not use our software, we can't explain why it is behaving in this way. Instead, you should ask the people who developed this RTSP client application. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacobhameiri at gmail.com Wed Jun 5 22:41:58 2013 From: jacobhameiri at gmail.com (jacob s) Date: Thu, 6 Jun 2013 08:41:58 +0300 Subject: [Live-devel] LIVE555 Streaming Media android port Message-ID: Hi, is there an android port for LIVE555 Streaming Media. preferably a native executable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Thu Jun 6 15:50:28 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Thu, 6 Jun 2013 23:50:28 +0100 Subject: [Live-devel] Larger streams breaking when opened through live555ProxyServer In-Reply-To: References: Message-ID: I also tried: sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.wmem_max=8388608 sysctl -w net.core.rmem_default=65536 sysctl -w net.core.wmem_default=65536 sysctl -w net.ipv4.tcp_rmem='4096 87380 8388608' sysctl -w net.ipv4.tcp_wmem='4096 65536 8388608' sysctl -w net.ipv4.tcp_mem='8388608 8388608 8388608' sysctl -w net.ipv4.route.flush=1 followed by restarting live555ProxyServer, it made no difference :( You can see the videos being recorded with ffmpeg from live555ProxyServer here: http://monitor.zanview.com ny ideas at all what is causing this? On 6 June 2013 14:55, Roman Gaufman wrote: > I tried to change increaseReceiveBufferTo() in: > liveMedia/BasicUDPSource.cpp liveMedia/MediaSession.cpp > liveMedia/MultiFramedRTPSource.cpp groupsock/GroupsockHelper.cpp > > To be 2129920 instead of 50 * 1024. > I also ran: sysctl -w net.core.rmem_max=2129920 > > Is there anyway to use increaseReceiveBufferTo() directly in > proxyServer/live555ProxyServer.cpp? - I'm not a developer and was not able > to figure it out, I tried adding it in a few different places but proxy > server wouldn't compile. > > After the above the result is the same :( - I can open several ffplay > processes on the same machine reading from the IP camera directly and the > image does not break, however if I start live555Proxy and play through that > the image breaks every few seconds or so. > > What else could be different reading with ffplay directly and reading with > ffplay through live555proxy? - I know the FAQ says: "There's nothing in our > code that can be 'losing' packets." but something is causing this loss? > > I've eliminated network and followed the advice about OS but it's still > breaking. > > I'm tearing my hair over this, please help :( > > > On 5 June 2013 19:41, Roman Gaufman wrote: > >> Here is a short video of it in action: >> https://www.youtube.com/watch?v=ShscnaNvNgw >> >> Output from live555ProxyServer: http://pastie.org/8011182 >> >> Opening directly with ffplay 'rtsp://admin at 192.168.88.13/media/video1' I >> very occasionally see: >> >> [h264 @ 0x7f9c7c003a00] Missing reference picture, default is 0/0 >> [h264 @ 0x7f9c7c003a00] decode_slice_header error >> >> But the image doesn't break and plays perfectly. >> >> When I open through live555ProxyServer the output is completely packed >> with stuff like this: >> >> [h264 @ 0x7fd93b024200] RTP: missed 1 packets >> [h264 @ 0x7fd93b024200] RTP: missed 2 packets >> Last message repeated 1 times >> [h264 @ 0x7fd93b024200] RTP: missed 3 packets >> [h264 @ 0x7fd93f80f600] negative number of zero coeffs at 77 33/6 >> [h264 @ 0x7fd93f80f600] error while decoding MB 77 33 >> [h264 @ 0x7fd93f80f600] concealing 4172 DC, 4172 AC, 4172 MV errors in I >> frame >> [h264 @ 0x7fd93b024200] RTP: missed 1 packets32KB sq= 0B f=6/6 >> Last message repeated 14 times 0KB vq= 469KB sq= 0B f=6/6 >> [h264 @ 0x7fd93f80e400] out of range intra chroma pred mode at 57 43 >> [h264 @ 0x7fd93f80e400] error while decoding MB 57 43 >> [h264 @ 0x7fd93f80e400] concealing 2992 DC, 2992 AC, 2992 MV errors in I >> frame >> [h264 @ 0x7fd93b024200] RTP: missed 1 packets42KB sq= 0B f=6/6 >> [h264 @ 0x7fd93b024200] RTP: missed 2 packets >> [h264 @ 0x7fd93b024200] RTP: missed 1 packets >> [h264 @ 0x7fd93b024200] RTP: missed 2 packets >> Last message repeated 1 times >> [h264 @ 0x7fd93b024200] RTP: missed 1 packets >> [h264 @ 0x7fd93b024200] RTP: missed 2 packets >> Last message repeated 1 times >> [h264 @ 0x7fd93b024200] RTP: missed 1 packets >> [h264 @ 0x7fd93f80f000] out of range intra chroma pred mode at 104 43 >> [h264 @ 0x7fd93f80f000] error while decoding MB 104 43 >> [h264 @ 0x7fd93f80f000] concealing 2945 DC, 2945 AC, 2945 MV errors in I >> frame >> >> If I reduce the resolution from 1920x1080 to 640x480 and reduce the >> bandwidth from 5mbit to 1mbit, I see no corruption through the proxy. It >> seems to only happen with large resolution/bitrate. >> >> This is not a bandwidth issue as I have a gigabit switch and both the >> camera and PC are connected straight to the switch. >> >> Also, I can open the camera stream multiple times from multiple instances >> of ffplay (also from multiple machines) and there is no corruption, the >> corruption only happens if opening through live555. >> >> The only modifications to the live555ProxyServer source code is ability >> to change the listening port and: OutPacketBuffer::maxSize = 500000; // >> bytes -- anything less and I see a bunch of errors like >> MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too >> large for our buffer size (60804). 316669 bytes of trailing data was >> dropped! >> >> I can reproduce this on 4 different IP cameras: ACTi E32, ACTi D71, >> Chinese noname and Sony SNC-CH210: ffplay works beautifully, live555proxy >> works only on small resolutions and causes corruption on anything 720P or >> up :( >> >> Any ideas? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 9 23:24:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Jun 2013 23:24:06 -0700 Subject: [Live-devel] Streaming faster than real time In-Reply-To: References: Message-ID: <737C2E7F-21C9-43B9-BE7B-4CB2B18FD038@live555.com> > When streaming RTP from a file (say video.h264) the video streams to the network at the real time rate, I assume by parsing the sps/pps info and throttling the network writes to that frame rate. Correct. > Is there a way to stream out at wire speed (or some scale) instead? If you want to send the data at 'wire speed', then what you want is "file transfer", not "streaming". In that case, just use a file transfer mechanism - e.g., HTTP or "scp". Alternatively, of course, it's also possible to use RTSP to request 'fast forward' streaming (i.e., with a "scale" value >1), although our RTSP server implementation currently does not implement this when streaming from a H.264 file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 10 01:11:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Jun 2013 01:11:15 -0700 Subject: [Live-devel] Does it may cause crash? In-Reply-To: References: Message-ID: On Jun 1, 2013, at 12:52 AM, ??? wrote: > I'm a newbee We know; your email address tells us this :-) > , and nice to see you all. > > at RTPInterface.cpp > line 354 > delete fSubChannelHashTable; > fSubChannelHashTable = NULL;// is it necessary? I don't know why a 'newbie' would be interested in the obscure details of the code, but they should use the most up-to-date version of the code (the only version of the code that we support). You were looking at an old version of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From androidmediateam at gmail.com Fri Jun 7 14:03:47 2013 From: androidmediateam at gmail.com (Sonay D) Date: Sat, 8 Jun 2013 02:33:47 +0530 Subject: [Live-devel] Hi, is there any java script or asp .NET source of project openRTSP or live555 or mmpeg media streaming servers? Message-ID: Hi Is there any java script or asp .NET source of project openRTSP or live555 or mmpeg media streaming servers that works on webpages without support of windows shell and command prompts? Please reply ASAP Thanking you With Regards AndroidMediaTeam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at isdcam.com Mon Jun 10 09:23:24 2013 From: jim at isdcam.com (Jim VanVorst) Date: Mon, 10 Jun 2013 09:23:24 -0700 Subject: [Live-devel] Streaming faster than real time In-Reply-To: <737C2E7F-21C9-43B9-BE7B-4CB2B18FD038@live555.com> References: <737C2E7F-21C9-43B9-BE7B-4CB2B18FD038@live555.com> Message-ID: Somewhere in the code you must have some logic to throttle to the parsed framerate, else you would stream out at wire speed since you're reading from a file and don't have to wait for live video. If I simply remove that throttle then I am magically RTP streaming at wire speed, i.e. a file copy over RTP. What I am trying to get is a pointer to where this throttle is in the code. I don't want to do anything fancy. Thanks. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Sunday, June 09, 2013 11:24 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Streaming faster than real time When streaming RTP from a file (say video.h264) the video streams to the network at the real time rate, I assume by parsing the sps/pps info and throttling the network writes to that frame rate. Correct. Is there a way to stream out at wire speed (or some scale) instead? If you want to send the data at 'wire speed', then what you want is "file transfer", not "streaming". In that case, just use a file transfer mechanism - e.g., HTTP or "scp". Alternatively, of course, it's also possible to use RTSP to request 'fast forward' streaming (i.e., with a "scale" value >1), although our RTSP server implementation currently does not implement this when streaming from a H.264 file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 10 11:37:11 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Jun 2013 11:37:11 -0700 Subject: [Live-devel] Streaming faster than real time In-Reply-To: References: <737C2E7F-21C9-43B9-BE7B-4CB2B18FD038@live555.com> Message-ID: <0FF96746-326D-4FB8-A57F-D220C05359A7@live555.com> > Somewhere in the code you must have some logic to throttle to the parsed framerate, else you would stream out at wire speed since you're reading from a file and don't have to wait for live video. If I simply remove that throttle then I am magically RTP streaming at wire speed, i.e. a file copy over RTP. What I am trying to get is a pointer to where this throttle is in the code. Well yeah, if you were to add uSecondsToGo = 0; to line 406 of "liveMedia/MultiFramedRTPSink.cpp", then you'd stream RTP packets at 'wire speed'. But why do this? The receiver would likely lose several of these packets (e.g., due to an overflowing socket buffer in the receiver's OS), with no way to recover the lost data. If you want to do a "file copy", then why not do it properly - e.g., using "scp", or by putting the file on a HTTP server? (Besides, once you've made changes to the supplied code, you can't expect any more support on this mailing list.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 10 15:08:14 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Jun 2013 15:08:14 -0700 Subject: [Live-devel] multicast port of client In-Reply-To: <201306051029163753850@163.com> References: <201306051029163753850@163.com> Message-ID: <98683650-F1CF-41D9-8201-3458573CF35E@live555.com> > I open two clients(using vlc) at the same host connecting to the same multicast source of live555 and I found that these two clients use the same port of rtp and rtcp Yes, of course they do, because that's what multicast means: Each packet is sent - just once - to a single (multicast) IP address and port number. (I.e., the IP address and port number are part of the packet, and are therefore the same for each recipient.) > I want these two clients at the same host use different port (like unicast),how can I to do? You can't, without actually getting two separate unicast streams - one to each port. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 10 15:22:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Jun 2013 15:22:15 -0700 Subject: [Live-devel] LIVE555 Streaming Media android port In-Reply-To: References: Message-ID: <22CFF287-A639-47BE-9AEF-F87B290C454A@live555.com> > Hi, is there an android port for LIVE555 Streaming Media. > 'Android' is just a type of Linux, so one of our existing "config.*linux*' configuration files should work. E.g., try running genMakefiles linux to create your Makefiles. > preferably a native executable? > The "LIVE555 Streaming Media" code is intended for (advanced) developers, and so is provided in source-code form only. (Binary executables are provided only for the "LIVE555 Media Server" application, because that is the only consumer-level application that we current provide. However, our Linux binary executable for the "LIVE555 Media Server" is for Intel x86 platforms, and probably won't work on most 'Android'-capable hardware.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 10 15:41:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Jun 2013 15:41:36 -0700 Subject: [Live-devel] Streaming H.264 avc In-Reply-To: <1370454112.21030.YahooMailNeo@web125905.mail.ne1.yahoo.com> References: <1370454112.21030.YahooMailNeo@web125905.mail.ne1.yahoo.com> Message-ID: > I wanted to know if the live supports streaming of H.264/MPEG4 AVC (part 10) (h264). Of course it does. We provide several examples of this. > > I ran the testOnDemandRTSPServer, > > but when I stream the h.264 movie and play it with vlc, the image is corrupted. > The format of the video is mpg. > > I don't know where I went wrong... Probably the filename (extension) that you used. Is your file a H.264 Video Elementary Stream file? If so, use a ".264" filename extension (e.g., "test.264" for streaming by "testOnDemandRTSPServer"). However, you said that "The format of your video is mpg". I don't know that that means, but the ".mpg" filename extension is used for MPEG-1 or 2 Audio+Video Program Stream files, which is almost certainly not what you want. So don't call your file "test.mpg". If you are sure that your file is a H.264 Video Elementary Stream file, then please put the file on a publically-accessible web (or FTP) server, and post the URL (not the file itself) to the "live-devel" mailing list, and we'll take a look at it, to see if we can figure out what's wrong. See http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work (which everyone was asked to read before posting to this mailing list). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacobhameiri at gmail.com Sun Jun 9 11:15:52 2013 From: jacobhameiri at gmail.com (jacob s) Date: Sun, 9 Jun 2013 21:15:52 +0300 Subject: [Live-devel] use live555 with raw rgb data input Message-ID: Is it possible to use live555 as an rtsp server that its input is raw rgb images and the output stream is mpeg4/h264 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Tue Jun 11 07:55:40 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Tue, 11 Jun 2013 14:55:40 +0000 Subject: [Live-devel] use live555 with raw rgb data input In-Reply-To: References: Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010F6C7A@postal.sonicfoundry.net> Jacob, You need an H.264 encoder before live555 will stream it. You could use x264 http://www.videolan.org/developers/x264.html or ffmepg with x264 or any other H.264 compressor. You may have to do a little post processing on the compressed stream: adjust for start codes, AU delimiters and PPS/SPS. Markus. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of jacob s Sent: Sunday, June 09, 2013 1:16 PM To: live-devel at ns.live555.com Subject: [Live-devel] use live555 with raw rgb data input Is it possible to use live555 as an rtsp server that its input is raw rgb images and the output stream is mpeg4/h264 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Tue Jun 11 09:33:08 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Tue, 11 Jun 2013 09:33:08 -0700 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <51B00F2B.10108@gosniias.ru> References: <51AD68A9.3050404@gosniias.ru> <51B00F2B.10108@gosniias.ru> Message-ID: <020101ce66c1$5d656350$183029f0$@com> Hello, > 04.06.2013 8:10, ?????? ?????: .. Snip > I can provide the additional output from the console. Client Milestone constantly sending requests to my server, and soon breaks the connection and then reconnects. Help solve the problem .. Snip I see the same problem with the Milestone smart client. The root cause is that Milestone is sending a session-specific OPTIONS command to the server, expecting this to act as a keep alive. The LIVE555 RTSP server implementation does not support using OPTIONS as a session keep alive, and there is nothing in the RFC regarding this being a valid thing to do. I think we all understand Ross' position of not wanting to include code to handle clients or servers that are way out of spec, but it is also nice for library code to interoperate well. My subclass of RTSPServer currently handles OPTIONS as a keep alive, but I had to include a lot of pointless boilerplate and subclassing to be able to do this, and I still had to modify the base RTSPServer to include a function to lookup an RTSPClientSession from a session id. If the attached patch could be included I would really appreciate it. Though, in the absence of that, it would be nice to be able to look up an RTSPClientSession and call its noteLiveness method from within a subclassed RTSPServer. Thanks, Chris Richardson WTI -------------- next part -------------- A non-text attachment was scrubbed... Name: OptionsKeepAlive.patch Type: application/octet-stream Size: 1082 bytes Desc: not available URL: From finlayson at live555.com Tue Jun 11 12:49:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Jun 2013 12:49:46 -0700 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <020101ce66c1$5d656350$183029f0$@com> References: <51AD68A9.3050404@gosniias.ru> <51B00F2B.10108@gosniias.ru> <020101ce66c1$5d656350$183029f0$@com> Message-ID: <4DE63BAC-9CA6-4F0B-858A-46649C3230DC@live555.com> Has anyone tried contacting "Milestone" and asked them why their client doesn't send RTCP "RR" packets - as they are supposed to - which would also act as a keep-alive? Or, alternatively, why it would not send (session-specific) "GET_PARAMETER" commands instead (which is what every other client who - for whatever reason - doesn't implement RTCP seems to do to indicate 'keep-alive')? If you haven't contacted them, then why not? If you are using their client application, then presumably you - or somebody you're associated with you - is a customer of theirs. So, why contact only us, and not them? I'm getting really tired of hearing about problems other companies' clients (or servers) only indirectly, via random third parties. We have probably the most widely-deployed RTSP/RTP implementation in the world. Why would "Milestone" (who I had never even heard of until a few days ago) not test their clients (and servers) against our code, and contact us when they found a problem? Why have I never heard even a peep from anyone at "Milestone", and why is there nobody from "Milestone" among the almost 2000 people on this mailing list? Nonetheless, because Chris Richardson's patch is so simple, I might add it to some future release of the LIVE555 software. I'm in no hurry to do so, however; I'd prefer to hear at least something back from "Milestone" first. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 11 17:34:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Jun 2013 17:34:55 -0700 Subject: [Live-devel] use live555 with raw rgb data input In-Reply-To: References: Message-ID: <8BF3031D-A705-4A27-BF03-1FC9088C4D06@live555.com> > Is it possible to use live555 as an rtsp server that its input is raw rgb images and the output stream is mpeg4/h264 ? Yes. You would need to write your own filter class (a subclass of "FramedFilter") that converts raw RGB frames to H.264 frames (NAL units). Your "OnDemandServerMediaSubsession" subclass's reimplementation of the "createNewStreamSource()" virtual function would create an object of your filter class (from your raw frame input source), and then pass it to a "H264VideoStreamDiscreteFramer" object. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Wed Jun 12 17:39:17 2013 From: kingaceck at 163.com (kingaceck) Date: Thu, 13 Jun 2013 08:39:17 +0800 Subject: [Live-devel] multicast port of client Message-ID: <201306130839167654263@163.com> >> I open two clients(using vlc) at the same host connecting to the same multicast source of live555 and I found that these two clients use the same port of rtp and rtcp >Yes, of course they do, because that's what multicast means: Each packet is sent - just once -> to a single (multicast) IP address and port number. (I.e., the IP address and port number are part of the packet, and are therefore the same for each recipient.) >> I want these two clients at the same host use different port (like unicast),how can I to do? >You can't, without actually getting two separate unicast streams - one to each port. If so,these two clients will send RR reports to the server and these RR reports use the same 'reportSenderSSRC'. So,the 'RTPTransmissionStats' will be overwrited and the statistics is confused . 2013-06-13 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 14 03:15:25 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Jun 2013 03:15:25 -0700 Subject: [Live-devel] ALERT: New LIVE555 version changes the signature of the "RTSPClient" constructor Message-ID: <5046A800-5EB4-4C28-8049-2B787470F511@live555.com> The latest version (2013.06.14) of the "LIVE555 Streaming Media" code changes the signature of the constructor of the "RTSPClient" class, and of its subclass "ProxyRTSPClient". If you have subclassed either of these classes in your code, then you will need to make a small change to your code accordingly. The change is to add a 'socket number to server' parameter (as the final parameter to the constructor). This socket number (if >=0) is the socket of an existing TCP connection to the server. This allows you to create a RTSP client object from an existing TCP connection. (If you do this, the supplied "rtsp://" URL must point to the server that's at the endpoint of the TCP connection.) If the 'socket number to server' parameter is <0 (e.g., -1), then the old behavior remains: A new TCP connection will be created for the class, by resolving the "rtsp://" URL. (The "RTSPClient::createNew()" function also takes a 'socket number to server' parameter, but this has a default value of -1, so existing code that creates "RTSPClient"s using only the "createNew()" function will not need to change.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ ps. I've also defined and implemented a custom "REGISTER" command that a server can use to notify a client (or a proxy) about the existence of one of its streams. The client (or proxy) can then use the same TCP connection to access the stream. This can be useful if the client (or proxy) is publicly accessible, but the server is behind a firewall or NAT. I'm not quite ready to release this feature yet, but should be able to soon. Stay tuned... -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 14 15:11:20 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Jun 2013 15:11:20 -0700 Subject: [Live-devel] multicast port of client In-Reply-To: <201306130839167654263@163.com> References: <201306130839167654263@163.com> Message-ID: <5C65C4A0-D61E-4D04-84E0-6B6D4AE31D6D@live555.com> > >> I open two clients(using vlc) at the same host connecting to the same multicast source of live555 and I found that these two clients use the same port of rtp and rtcp > >Yes, of course they do, because that's what multicast means: Each packet is sent - just once -> to a single (multicast) IP address and port number. (I.e., the IP address and port number are part of the packet, and are therefore the same for each recipient.) > >> I want these two clients at the same host use different port (like unicast),how can I to do? > >You can't, without actually getting two separate unicast streams - one to each port. > > If so,these two clients will send RR reports to the server That's true only for SSM ("source-specific multicast") streams. For ASM ("any-source multicast") streams, RTCP "RR" reports are sent to the whole multicast group - not back to the server. > and these RR reports use the same 'reportSenderSSRC'. No, because each participant in the multicast session - i.e., the sender, and each of the recipients - has a different SSRC. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xieyongda at gmail.com Thu Jun 13 20:03:48 2013 From: xieyongda at gmail.com (=?GB2312?B?0LvTwLTv?=) Date: Fri, 14 Jun 2013 11:03:48 +0800 Subject: [Live-devel] is it work? Message-ID: I add a public member function fro RTSPClient, so that I can create the connection outside and setup TCP socket for it; void RTSPClient::setSocketNum(int ioSocket) { resetTCPSockets(); fInputSocketNum=fOutputSocketNum=ioSocket; if(ioSocket>=0){ envir().taskScheduler().setBackgroundHandling(fInputSocketNum, SOCKET_READABLE|SOCKET_EXCEPTION, (TaskScheduler::BackgroundHandlerProc*)&incomingDataHandler, this); } } -- by:crazyevent -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 14 15:50:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Jun 2013 15:50:55 -0700 Subject: [Live-devel] is it work? In-Reply-To: References: Message-ID: <2A1D0083-D118-416A-B4CE-77E433352BD5@live555.com> On Jun 13, 2013, at 8:03 PM, ??? wrote: > I add a public member function fro RTSPClient If possible, you shouldn't modify the existing code. It's better to subclass "RTSPClient", and add your new member functions to your subclass. > , so that I can create the connection outside and setup TCP socket for it Instead of this, please upgrade to the latest version of the "LIVE555 Streaming Media" code, and use the (updated) "RTSPClient::createNew()" function that takes a "socketNumToServer" parameter. See: http://lists.live555.com/pipermail/live-devel/2013-June/017085.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvika.meiseles at gmail.com Sat Jun 15 04:58:09 2013 From: zvika.meiseles at gmail.com (Zvika Meiseles) Date: Sat, 15 Jun 2013 14:58:09 +0300 Subject: [Live-devel] Larger streams breaking when opened through live555ProxyServer Message-ID: I'm having a similar (or related) issue. I'm not using 'live555ProxyServer', since it does not fit my needs. I have implemented my own proxy, and am seeing breaks in the video as well. The breaks disappear when I substitute the 'input' to be a file, instead of an RTP network stream (I have an intermediate buffer that presents the data in an identical stream, no matter what the source is). This leads me to think that, for some unknown reason, there's a problem when the same code is both sending and receiving (multicast?) network traffic. I have not yet been able to confirm or disprove this assumption. (btw: I'm currently working on a Linux machine, but I saw similar behavior on Windows). Zvika -------------- next part -------------- An HTML attachment was scrubbed... URL: From nixchun at gmail.com Mon Jun 17 01:47:37 2013 From: nixchun at gmail.com (Nix Lo) Date: Mon, 17 Jun 2013 16:47:37 +0800 Subject: [Live-devel] Report one possible bug about function createJPEGHeader() Message-ID: Dear Sir: About the implementation of function createJPEGHeader() in file JPEGVideoRTPSource.cpp, the 1st time the formula of determining the value of variable "tableSize" is: unsigned tableSize = numQtables == 1 ? qtlen : qtlen/2; I think it should be: unsigned tableSize = numQtables == 1 ? qtlen/2 : qtlen; It makes sense that the size of quantization table is 64 bytes long if there's only one quantization table. Would you please double check if my point is correct? Thank you very much. Sincerely, Nix Lo -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuliangcheng1985 at 126.com Mon Jun 17 07:49:31 2013 From: fuliangcheng1985 at 126.com (fuliangcheng1985) Date: Mon, 17 Jun 2013 22:49:31 +0800 (CST) Subject: [Live-devel] use testOnDemandServer to steaming local video Message-ID: <3401fcd.1662c.13f529cbe74.Coremail.fuliangcheng1985@126.com> Hi?everyone: I have a problem that: i put a .mp4 video in the live/testprog/ and rename it as "test.m4e" and then i run the command "./testOnDemandRTSPServer" in order to streaming the file "test.m4e", but when i open an vlc media player to play this streaming just like "vlc rtsp://192.168.1.103:8554/mpeg4ESVideoTest", the error like? "MPEG4VideoStreamParser::parseVideoObjectPlane():: marker bit not set" "MPEG4VideoStreamParser::parseVideoObjectPlane():: Saw unexpected code 0x13f" occured, is there something wrong i have done these steps? or the file format of test.m4e is not correct Thandk you very much? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 17 22:31:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Jun 2013 22:31:46 -0700 Subject: [Live-devel] Report one possible bug about function createJPEGHeader() In-Reply-To: References: Message-ID: <72D87482-B769-41F3-8063-D02181D98F7F@live555.com> > About the implementation of function createJPEGHeader() in file JPEGVideoRTPSource.cpp, the 1st time the formula of determining the value of variable "tableSize" is: > > unsigned tableSize = numQtables == 1 ? qtlen : qtlen/2; > > I think it should be: > > unsigned tableSize = numQtables == 1 ? qtlen/2 : qtlen; No, because "qtlen" is the total length of all of the (1 or 2) quantization tables, and (the computed) "tableSize" is intended to be the size of a single table. The existing code is correct. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 17 22:37:21 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Jun 2013 22:37:21 -0700 Subject: [Live-devel] use testOnDemandServer to steaming local video In-Reply-To: <3401fcd.1662c.13f529cbe74.Coremail.fuliangcheng1985@126.com> References: <3401fcd.1662c.13f529cbe74.Coremail.fuliangcheng1985@126.com> Message-ID: <898F5E13-9EBD-40F8-891A-B70D08AFC60B@live555.com> > i put a .mp4 video in the live/testprog/ and rename it as "test.m4e" That's your problem. Our servers can stream files with a ".m4e" filename extension only it they are MPEG-4 Video Elementary Stream files. Your file was apparently not this type of file. Note that our servers currently cannot stream ".mp4"-format files. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Mon Jun 17 23:20:32 2013 From: ashvyrkin at gosniias.ru (Andrey) Date: Tue, 18 Jun 2013 10:20:32 +0400 Subject: [Live-devel] windows winsock error 10038 Message-ID: <51BFFC30.1090409@gosniias.ru> Hi, Ross. I am compelled to write again from the already overexposed challenge posed SingleStep (). After a call to select () the invalid socket error occurs. It occurs in multiple-connected disabled client to the server, and the server will eventually fall. I know that you can override internalError () function, but it would still understand the cause of the error. After testing, it was found out that the error is really the choice of previously closed socket fClientInputSocket to function RTSPClientConnection :: closeSockets (). If the client socket will never close at the end of the session (although this is wrong), the error does not occur. Perhaps when a new socket descriptor is given to just closed? I do not understand what the problem is. From finlayson at live555.com Mon Jun 17 23:33:16 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Jun 2013 23:33:16 -0700 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <51BFFC30.1090409@gosniias.ru> References: <51BFFC30.1090409@gosniias.ru> Message-ID: <9885B756-EEB4-4F75-8CCA-E0C0C39E12FD@live555.com> > After a call to select () the invalid socket error occurs. It occurs in multiple-connected disabled client to the server, and the server will eventually fall. I know that you can override internalError () function, but it would still understand the cause of the error. The problem is that you are closing a socket, but without turning off background checking on it - so the event loop ("select()") still erroneously thinks that the socket is in use. To fix your problem, make sure that you disable background checking on each of your sockets - using "TaskScheduler::turnOffBackgroundReadHandling()" - before you close the socket. (Note that this is already done in all places in our library code that create sockets - so the problem must be occurring somewhere in your application code.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Tue Jun 18 00:44:54 2013 From: ashvyrkin at gosniias.ru (Andrey) Date: Tue, 18 Jun 2013 11:44:54 +0400 Subject: [Live-devel] windows winsock error 10038 Message-ID: <51C00FF6.1080004@gosniias.ru> Thanks for the quick reply. However, the error occurs even if the test code testOnDemandRTSPServer reuseFirstSource set to True. I have not changed anything in the code, except the reuseFirstSource. The error occurs on the socket fClientInputSocket of RTSPServer.cpp. Closing the socket occurs after the call closeSockets () in the destructor ~ RTSPClientConnection (), respectively, which is called when the session with the client. The functions of the closeSockets () before closing the socket is called disableBackgroundHandling (fClientInputSocket). The idea is all right, and select () function should not be to access a closed socket. However, after repeated reconnect the client to the server in the select () function generates an error. The problem arises only when the true meaning of reuseFirstSource and multiple client reconnects to the server. Perhaps the problem is disableBackgroundHandling, in any case, the error is random and can occur as a reconnection with the client, and more than a hundred. From finlayson at live555.com Tue Jun 18 00:50:41 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Jun 2013 00:50:41 -0700 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <51C00FF6.1080004@gosniias.ru> References: <51C00FF6.1080004@gosniias.ru> Message-ID: > Thanks for the quick reply. However, the error occurs even if the test code testOnDemandRTSPServer reuseFirstSource set to True. I have not changed anything in the code, except the reuseFirstSource. If that's the case, then unfortunately you're going to have to track down the specific problem in our code that is causing this - because nobody else has reported seeing this issue. (As always, I assume that you're using the latest version of the LIVE555 software - the only version that we support.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktlee at digicaps.com Tue Jun 18 00:29:52 2013 From: ktlee at digicaps.com (=?ks_c_5601-1987?B?wMyx4sXDL8fDt6fG+7Czud8yxsA=?=) Date: Tue, 18 Jun 2013 16:29:52 +0900 Subject: [Live-devel] Full HD Contents. trickplay question Message-ID: <2D2A3255ACBA744DA56BD7681C7DF2CA034D181E@main.digicaps.co.kr> Hello everyone, I?m testing a Trick-play function using Live555 and turned out most of the contents tested are working well in STB. But some 2x, 4x converted to testMPEG2TransportStreamTrickPlay are not played properly in STB. I?d like to know if there?s something I did wrong. I used content information is as follows: - Test original HD contents (ts): http://aslike.ipdisk.co.kr:8000/live555/ChunMyung.ts - index file (tsx); http://aslike.ipdisk.co.kr:8000/live555/ChunMyung.tsx - 2scale ts file: http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_02scale.ts - 4scale ts file: http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_04scale.ts Thank you Dennis Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Tue Jun 18 01:09:10 2013 From: ashvyrkin at gosniias.ru (Andrey) Date: Tue, 18 Jun 2013 12:09:10 +0400 Subject: [Live-devel] MilestoneXProtect playing problem Message-ID: <51C015A6.9030001@gosniias.ru> Unfortunately I have a week waiting for a response from the Milestone, but it is not. What if I use the reclamationTestSeconds = 0 when creating RTSPServer. In theory this should solve the problem. From finlayson at live555.com Tue Jun 18 01:22:17 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Jun 2013 01:22:17 -0700 Subject: [Live-devel] Full HD Contents. trickplay question In-Reply-To: <2D2A3255ACBA744DA56BD7681C7DF2CA034D181E@main.digicaps.co.kr> References: <2D2A3255ACBA744DA56BD7681C7DF2CA034D181E@main.digicaps.co.kr> Message-ID: <8FE3196C-0476-40E9-BD11-A7F95B77E17E@live555.com> > I?m testing a Trick-play function using Live555 and turned out most of the contents tested are working well in STB. > But some 2x, 4x converted to testMPEG2TransportStreamTrickPlay are not played properly in STB. > > I?d like to know if there?s something I did wrong. > > I used content information is as follows: > - Test original HD contents (ts): http://aslike.ipdisk.co.kr:8000/live555/ChunMyung.ts > - index file (tsx); http://aslike.ipdisk.co.kr:8000/live555/ChunMyung.tsx > - 2scale ts file: http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_02scale.ts > - 4scale ts file: http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_04scale.ts I downloaded these, and found that each of the ".ts" files were playable by the VLC media player. So you will have to ask the manufacturer of your STB why it cannot play them. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktlee at digicaps.com Tue Jun 18 02:33:56 2013 From: ktlee at digicaps.com (=?ks_c_5601-1987?B?wMyx4sXDL8fDt6fG+7Czud8yxsA=?=) Date: Tue, 18 Jun 2013 18:33:56 +0900 Subject: [Live-devel] Full HD Contents. trickplay question (with VLC) Message-ID: <2D2A3255ACBA744DA56BD7681C7DF2CA03610C4D@main.digicaps.co.kr> Hi Ross I had already conducted a test with VLC Media Player before testing with STB. (VLC v.2.0.6 and VLC v2.0.7) As you can see original file, 2x file is not animated as original file and 4x file is somehow animated but looks quite unnatural. Could you please check it out again? - 2scale ts file: http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_02scale.ts - 4scale ts file: http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_04scale.ts Thank you Dennis Lee > I?m testing a Trick-play function using Live555 and turned out most of the contents tested are working well in STB. > But some 2x, 4x converted to testMPEG2TransportStreamTrickPlay are not played properly in STB. > > I?d like to know if there?s something I did wrong. > > I used content information is as follows: > - Test original HD contents (ts): > http://aslike.ipdisk.co.kr:8000/live555/ChunMyung.ts > - index file (tsx); > http://aslike.ipdisk.co.kr:8000/live555/ChunMyung.tsx > - 2scale ts file: > http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_02scale.ts > - 4scale ts file: > http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_04scale.ts I downloaded these, and found that each of the ".ts" files were playable by the VLC media player. So you will have to ask the manufacturer of your STB why it cannot play them. From: ???/?????2? Sent: Tuesday, June 18, 2013 4:30 PM To: 'live-devel at lists.live555.com' Subject: Full HD Contents. trickplay question Hello everyone, I?m testing a Trick-play function using Live555 and turned out most of the contents tested are working well in STB. But some 2x, 4x converted to testMPEG2TransportStreamTrickPlay are not played properly in STB. I?d like to know if there?s something I did wrong. I used content information is as follows: - Test original HD contents (ts): http://aslike.ipdisk.co.kr:8000/live555/ChunMyung.ts - index file (tsx); http://aslike.ipdisk.co.kr:8000/live555/ChunMyung.tsx - 2scale ts file: http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_02scale.ts - 4scale ts file: http://aslike.ipdisk.co.kr:8000/live555/ChunMyung_04scale.ts Thank you Dennis Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Tue Jun 18 04:11:52 2013 From: ashvyrkin at gosniias.ru (Andrey) Date: Tue, 18 Jun 2013 15:11:52 +0400 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <51C015A6.9030001@gosniias.ru> References: <51C015A6.9030001@gosniias.ru> Message-ID: <51C04078.5090001@gosniias.ru> 18.06.2013 12:09, Andrey ?????: > Unfortunately I have a week waiting for a response from the Milestone, > but it is not. What if I use the reclamationTestSeconds = 0 when > creating RTSPServer. In theory this should solve the problem. If I set reclamationTestSeconds = 0, the session with the Milestone Client does not stop. However, if I understand correctly, in this situation the session on the server side will never break? Even if no RTSP commands - or RTCP "RR" packets - from the client are received? From Serge.Grondin at miranda.com Tue Jun 18 07:31:25 2013 From: Serge.Grondin at miranda.com (Serge.Grondin at miranda.com) Date: Tue, 18 Jun 2013 10:31:25 -0400 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: References: <51C00FF6.1080004@gosniias.ru> Message-ID: Hi Ross and Andrey, I got the exact same bug on my Linux server, a random "bad file descriptor" error that kills my server every 24 hours or so using RTP over TCP streaming. Hopefully I have an auto restart mechanism that respawn my server but that's not really great solution. Same thing for me, I have not changed anything in the code and I don't even close or open any TCP socket (and I don't play with background handling). Last week I decided to take a deeper look into it and I think I have found a track but I don't have a good solution for it. That thing is really hard to reproduce but I think the best way to get it is to kill the client process listening to a TCP stream connected to live555 server (and clients reuse the same source flag). On my server the problem seems to come when the connection between the server and the client is lost while streaming TCP for a long time. The problem I found is in RTPInterface.cpp file -> SocketDescriptor::tcpReadHandler1 line 422 If readSocket fails (-1) it triggers a deletion of the SocketDescriptor object However this is leaving a dangling pointer in the HashTable in RTPInterface (lookupSocketDescriptor) while the "OnDemandServerMediaSubsession" is still alive. Then a new client comes, RTPInterface::startNetworkReading is called and "registerRTPInterface" is called again on the dead SocketDescriptor, registering the dead socket for background handling... boom! You get the file descriptor error and the server dies. I found it by adding a few "printf" in this area, I suggest you should do the same. I don't have a clear idea how to fix that but I'm happy I'm not the only one getting it. Thanks! Serge Grondin Miranda Technnologies From: Ross Finlayson To: LIVE555 Streaming Media - development & use , Date: 2013-06-18 04:18 Subject: Re: [Live-devel] windows winsock error 10038 Sent by: live-devel-bounces at ns.live555.com Thanks for the quick reply. However, the error occurs even if the test code testOnDemandRTSPServer reuseFirstSource set to True. I have not changed anything in the code, except the reuseFirstSource. If that's the case, then unfortunately you're going to have to track down the specific problem in our code that is causing this - because nobody else has reported seeing this issue. (As always, I assume that you're using the latest version of the LIVE555 software - the only version that we support.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From chris at gotowti.com Tue Jun 18 08:39:19 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Tue, 18 Jun 2013 08:39:19 -0700 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <51C04078.5090001@gosniias.ru> References: <51C015A6.9030001@gosniias.ru> <51C04078.5090001@gosniias.ru> Message-ID: <008d01ce6c3a$028f1ec0$07ad5c40$@com> That is correct. You can verify the server will keep sending data for each broken stream by simply killing the client process and restarting it. The network usage will continue to rise. The best solution is to either subclass RTSPServer and handle OPTIONS as a keep-alive request, or apply the patch I sent previously. Or ask very nicely for Ross to apply it. Thanks, Chris Richardson WTI -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Andrey Sent: Tuesday, June 18, 2013 4:12 AM To: live-devel at ns.live555.com Subject: Re: [Live-devel] MilestoneXProtect playing problem 18.06.2013 12:09, Andrey ?????: > Unfortunately I have a week waiting for a response from the Milestone, > but it is not. What if I use the reclamationTestSeconds = 0 when > creating RTSPServer. In theory this should solve the problem. If I set reclamationTestSeconds = 0, the session with the Milestone Client does not stop. However, if I understand correctly, in this situation the session on the server side will never break? Even if no RTSP commands - or RTCP "RR" packets - from the client are received? _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Tue Jun 18 12:55:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Jun 2013 12:55:36 -0700 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: References: <51C00FF6.1080004@gosniias.ru> Message-ID: > The problem I found is in RTPInterface.cpp file > > -> SocketDescriptor::tcpReadHandler1 line 422 > If readSocket fails (-1) it triggers a deletion of the SocketDescriptor object > Correct. > > However this is leaving a dangling pointer in the HashTable in RTPInterface (lookupSocketDescriptor) > Incorrect - because the "SocketDescriptor" destructor calls "removeSocketDescription()", which will remove the "SocketDescriptor" object from the hash table. (Note that the "SocketDescriptor" destructor also calls "turnOffBackgroundReadHandling()" on the socket, so that this socket will no longer get used in the event loop's "select()".) As I noted earlier, the "bad file descriptor" error (or other socket error) in "select()" is caused by a socket getting closed somewhere without "turnOffBackgroundReadHandling()" also being called for the socket. It's conceivable that there is a bug in the LIVE555 code somewhere that is causing this to happen - in which case I invite people to try to track it down. However, what you described above is not it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 18 13:20:22 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Jun 2013 13:20:22 -0700 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <008d01ce6c3a$028f1ec0$07ad5c40$@com> References: <51C015A6.9030001@gosniias.ru> <51C04078.5090001@gosniias.ru> <008d01ce6c3a$028f1ec0$07ad5c40$@com> Message-ID: <71A0F74F-E5D7-4C0A-9766-3415185688E6@live555.com> On Jun 18, 2013, at 8:39 AM, Chris Richardson (WTI) wrote: > That is correct. You can verify the server will keep sending data for each broken stream by simply killing the client process and restarting it. No, it doesn't do any such thing (unless the word "process" means something very different for you than for everyone else :-) In any case, this is now a moot point, because I have just installed a new version - 2013.06.18 - of the "LIVE555 Streaming Media" that recognizes incoming "OPTIONS" requests - with a "Session:" id - as indicating client liveness (as you suggested). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Tue Jun 18 13:40:55 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Tue, 18 Jun 2013 13:40:55 -0700 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <71A0F74F-E5D7-4C0A-9766-3415185688E6@live555.com> References: <51C015A6.9030001@gosniias.ru> <51C04078.5090001@gosniias.ru> <008d01ce6c3a$028f1ec0$07ad5c40$@com> <71A0F74F-E5D7-4C0A-9766-3415185688E6@live555.com> Message-ID: <00b001ce6c64$23778d50$6a66a7f0$@com> Hi Ross, I do understand what a process is and believe my definition to be the same as most other people. Regardless of that, I can tell you that if you set 'reclamationTestSeconds' to 0 that it does stop the server from killing non-active client sessions, including those that have been closed in a non-graceful manner. Isn't this the expected behavior? It is easily reproducible, at least on my Windows XP PC, with testOnDemandRTSPServer and openRTSP using the following procedure: 1. Start testOnDemandRTSPServer 2. Start openRTSP with the URL of the H.264 stream on the testOnDemandRTSPServer instance 3. Allow openRTSP to stream for a few seconds 4. Kill openRTSP with Ctrl+C 5. Verify the testOnDemandRTSPServer instance is still (attempting to) send data via the large amount of continuing console output 6. Kill and restart the testOnDemandRTSPServer 7. Run the same test as above but with VLC, and close the stream gracefully in VLC using the stop command 8. Verify that the server stops writing out console messages I find it hard to believe that nobody else would be able to reproduce this, given that the whole point of 'reclamationTestSeconds' is to handle the above situation. If we disable the reclamationTestSeconds feature by using a value of 0, I would expect the server to behave exactly in that way. Thanks, Chris Richardson WTI From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, June 18, 2013 1:20 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] MilestoneXProtect playing problem On Jun 18, 2013, at 8:39 AM, Chris Richardson (WTI) wrote: That is correct. You can verify the server will keep sending data for each broken stream by simply killing the client process and restarting it. No, it doesn't do any such thing (unless the word "process" means something very different for you than for everyone else :-) In any case, this is now a moot point, because I have just installed a new version - 2013.06.18 - of the "LIVE555 Streaming Media" that recognizes incoming "OPTIONS" requests - with a "Session:" id - as indicating client liveness (as you suggested). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Serge.Grondin at miranda.com Tue Jun 18 13:51:19 2013 From: Serge.Grondin at miranda.com (Serge.Grondin at miranda.com) Date: Tue, 18 Jun 2013 16:51:19 -0400 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: References: <51C00FF6.1080004@gosniias.ru> Message-ID: You are right about the "removeSocketDescription" my explication was not good, forget about this. I should not have waste time trying to find an explanation because I don't have a clear view why this is happening. However this is what I have found so far, if this can help anybody track this down. So it first start with a readSocket failure on socket X, this trigs a deletion if SocketDescriptor, this I am sure. Now I do see that just after that background handling is turned on again on the socket X, just when a new TCP client connects using socket Y and is asking for the stream. Right after that boom... bad file descriptor error. This new background handling comes from a call in RTPInterface::startNetworkReading, this is what I found by logging all access to all TCP sockets in the code. It looks like something is not cleaned up properly when the readSocket failure occurs. I will try to create a test that reproduces the problem easily because so far this is very hard to repro, it is a question of having the right timing. Hope this help. Serge Miranda Technologies From: Ross Finlayson To: LIVE555 Streaming Media - development & use , Date: 2013-06-18 16:04 Subject: Re: [Live-devel] windows winsock error 10038 Sent by: live-devel-bounces at ns.live555.com The problem I found is in RTPInterface.cpp file -> SocketDescriptor::tcpReadHandler1 line 422 If readSocket fails (-1) it triggers a deletion of the SocketDescriptor object Correct. However this is leaving a dangling pointer in the HashTable in RTPInterface (lookupSocketDescriptor) Incorrect - because the "SocketDescriptor" destructor calls "removeSocketDescription()", which will remove the "SocketDescriptor" object from the hash table. (Note that the "SocketDescriptor" destructor also calls "turnOffBackgroundReadHandling()" on the socket, so that this socket will no longer get used in the event loop's "select()".) As I noted earlier, the "bad file descriptor" error (or other socket error) in "select()" is caused by a socket getting closed somewhere without "turnOffBackgroundReadHandling()" also being called for the socket. It's conceivable that there is a bug in the LIVE555 code somewhere that is causing this to happen - in which case I invite people to try to track it down. However, what you described above is not it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From finlayson at live555.com Tue Jun 18 13:57:40 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Jun 2013 13:57:40 -0700 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <00b001ce6c64$23778d50$6a66a7f0$@com> References: <51C015A6.9030001@gosniias.ru> <51C04078.5090001@gosniias.ru> <008d01ce6c3a$028f1ec0$07ad5c40$@com> <71A0F74F-E5D7-4C0A-9766-3415185688E6@live555.com> <00b001ce6c64$23778d50$6a66a7f0$@com> Message-ID: <2273A3E5-8AA4-48D8-9C85-554E49F780DD@live555.com> > if you set ?reclamationTestSeconds? to 0 that it does stop the server from killing non-active client sessions, including those that have been closed in a non-graceful manner. Isn?t this the expected behavior? Yes - it is the intended behavior. I never intended to imply otherwise. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Tue Jun 18 14:16:32 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Tue, 18 Jun 2013 14:16:32 -0700 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <2273A3E5-8AA4-48D8-9C85-554E49F780DD@live555.com> References: <51C015A6.9030001@gosniias.ru> <51C04078.5090001@gosniias.ru> <008d01ce6c3a$028f1ec0$07ad5c40$@com> <71A0F74F-E5D7-4C0A-9766-3415185688E6@live555.com> <00b001ce6c64$23778d50$6a66a7f0$@com> <2273A3E5-8AA4-48D8-9C85-554E49F780DD@live555.com> Message-ID: <00d901ce6c69$1ddece30$599c6a90$@com> Hi Ross, I'm relieved to hear I was not mistaken in my original posting. I also forgot to say thanks for including that patch in the new software. Thanks! Chris Richardson WTI From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, June 18, 2013 1:58 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] MilestoneXProtect playing problem if you set 'reclamationTestSeconds' to 0 that it does stop the server from killing non-active client sessions, including those that have been closed in a non-graceful manner. Isn't this the expected behavior? Yes - it is the intended behavior. I never intended to imply otherwise. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Tue Jun 18 23:13:53 2013 From: ashvyrkin at gosniias.ru (=?UTF-8?B?0JDQvdC00YDQtdC5?=) Date: Wed, 19 Jun 2013 10:13:53 +0400 Subject: [Live-devel] MilestoneXProtect playing problem In-Reply-To: <71A0F74F-E5D7-4C0A-9766-3415185688E6@live555.com> References: <51C015A6.9030001@gosniias.ru> <51C04078.5090001@gosniias.ru> <008d01ce6c3a$028f1ec0$07ad5c40$@com> <71A0F74F-E5D7-4C0A-9766-3415185688E6@live555.com> Message-ID: <51C14C21.1090803@gosniias.ru> 19.06.2013 0:20, Ross Finlayson ?????: > > On Jun 18, 2013, at 8:39 AM, Chris Richardson (WTI) > wrote: > >> That is correct. You can verify the server will keep sending data >> for each broken stream by simply killing the client process and >> restarting it. > > No, it doesn't do any such thing (unless the word "process" means > something very different for you than for everyone else :-) > > In any case, this is now a moot point, because I have just installed a > new version - 2013.06.18 - of the "LIVE555 Streaming Media" that > recognizes incoming "OPTIONS" requests - with a "Session:" id - as > indicating client liveness (as you suggested). > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel Chris, thanks for the patch and Ross, thank you included it in the new release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 19 00:00:40 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Jun 2013 00:00:40 -0700 Subject: [Live-devel] New (custom) "REGISTER" command - for advertising a RTSP stream to a client or proxy server Message-ID: <18AA1B46-D061-40CE-8323-99CC3E6D8D92@live555.com> The latest version of the "LIVE555 Streaming Media" software supports a new, custom RTSP command: "REGISTER". This request is currently non-standard; however, I will shortly be submitting an IETF Internet-Draft document that describes it. This command can be used to 'advertise' a RTSP stream (given by a "rtsp://" URL) to a client application, or to a proxy server. In particular, a server can use this command to advertise one of its own streams to a client application (or proxy server), which then gets to reuse the TCP connection on which it received the request. This can be useful if the server is behind a firewall or NAT (e.g., on a mobile phone data network), but the client application (or proxy server) is on the public Internet. For (non-proxy) Servers: ==================== A LIVE555-based server application can 'advertise' one of its streams - described by a "ServerMediaSession" object in a "RTSPServer" - by calling the new member function: "RTSPServer::registerStream()" specifying the remote client application (or proxy server)'s name or IP address, and port number. This will send a "REGISTER" request, advertising the stream. For Proxy Servers: =============== To create a proxy server that automatically accepts incoming stream 'advertisements' (i.e., "REGISTER" requests), and proxies the advertised "rtsp://" URL for each such incoming request, create a "RTSPServerWithREGISTERProxying" rather than a usual "RTSPServer". (see "liveMedia/include/RTSPServer.hh"). (For an illustration of this, note how we implement the new '-R' command-line option for the "LIVE555 Proxy Server".) For Client Applications: =================== A client application can create a simple server that accepts incoming 'advertisements' (i.e., "REGISTER" requests), and then automatically creates a new "RTSPClient" object to handle the "rtsp://" URL specified by each such incoming request. To do this, create a "HandlerServerForREGISTERCommand" object, by calling "HandlerServerForREGISTERCommand::createNew()" (see "liveMedia/include/RTSPClient.hh"). (For an illustration of this, note how we implement the new '-R' command-line option for the "openRTSP" application.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From WILLIAM.C.BOYKIN at saic.com Wed Jun 19 11:26:24 2013 From: WILLIAM.C.BOYKIN at saic.com (Boykin, William C.) Date: Wed, 19 Jun 2013 11:26:24 -0700 Subject: [Live-devel] testh264videototransportstream Message-ID: <1F03D0DC29EC2F4198A8B37F37628CE208A007D5@0461-its-exmb05.us.saic.com> Hi, I was comparing ffmpeg.exe to testh264videototransportstream exe and have a question. 1. ffmpeg -i video.264 -vcodec copy video.ts I see about 4 or 5 188 byte metadata payloads per second. 2. testh264videototransportstream exe video.264 I see about one 188 bytes metadata payloads per second. Is there any way to get testh264videototransportstream exe to increase or match the 188 byte metadat payloads that ffmpeg produces ? Thanks ahead. Bill "Woody" Boykin | SAIC Software Engineer IV | Software Solution Team 6725 Odyssey Drive Huntsville, AL 35806 Room : 370 Phone : 256-971-6738 email : william.c.boykin at saic.com "It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive." ~ Steve McConnell -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 19 12:04:10 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Jun 2013 12:04:10 -0700 Subject: [Live-devel] testh264videototransportstream In-Reply-To: <1F03D0DC29EC2F4198A8B37F37628CE208A007D5@0461-its-exmb05.us.saic.com> References: <1F03D0DC29EC2F4198A8B37F37628CE208A007D5@0461-its-exmb05.us.saic.com> Message-ID: <986BD616-9DB3-4F9C-9DE6-8F869299C882@live555.com> > I was comparing ffmpeg.exe to testh264videototransportstream exe and have a question. > > 1. ffmpeg -i video.264 -vcodec copy video.ts > > I see about 4 or 5 188 byte metadata payloads per second. > > 2. testh264videototransportstream exe video.264 > > I see about one 188 bytes metadata payloads per second. > > Is there any way to get testh264videototransportstream exe to increase or match the 188 byte metadat payloads that ffmpeg produces ? What do you mean by "metadata packets"? Are you referring to Transport Stream "PAT" (Program Association Table) and/or "PMT" (Program Map Table) packets? If so, then the frequency at which these packets are inserted into the output Transport Stream is determined by the constants "PAT_FREQUENCY" and "PMT_FREQUENCY", defined in "liveMedia/MPEG2TransportStreamMultiplexor.cpp". If you decrease these constants, then you will increase the frequency at which the corresponding (PAT or PMT) packets are inserted into the output stream. (As you can see, these constants are actually misnamed. They should have been called "*_PERIOD", not "*_FREQUENCY".) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From WILLIAM.C.BOYKIN at saic.com Wed Jun 19 12:45:59 2013 From: WILLIAM.C.BOYKIN at saic.com (Boykin, William C.) Date: Wed, 19 Jun 2013 12:45:59 -0700 Subject: [Live-devel] testh264videototransportstream References: <1F03D0DC29EC2F4198A8B37F37628CE208A007D5@0461-its-exmb05.us.saic.com> <986BD616-9DB3-4F9C-9DE6-8F869299C882@live555.com> Message-ID: <1F03D0DC29EC2F4198A8B37F37628CE208A007D6@0461-its-exmb05.us.saic.com> Ross, Thanks for the reply, I'll try decreasing the constants. Bill "Woody" Boykin | SAIC Software Engineer IV | Software Solution Team 6725 Odyssey Drive Huntsville, AL 35806 Room : 370 Phone : 256-971-6738 email : william.c.boykin at saic.com "It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive." ~ Steve McConnell ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Wed 6/19/2013 2:04 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testh264videototransportstream I was comparing ffmpeg.exe to testh264videototransportstream exe and have a question. 1. ffmpeg -i video.264 -vcodec copy video.ts I see about 4 or 5 188 byte metadata payloads per second. 2. testh264videototransportstream exe video.264 I see about one 188 bytes metadata payloads per second. Is there any way to get testh264videototransportstream exe to increase or match the 188 byte metadat payloads that ffmpeg produces ? What do you mean by "metadata packets"? Are you referring to Transport Stream "PAT" (Program Association Table) and/or "PMT" (Program Map Table) packets? If so, then the frequency at which these packets are inserted into the output Transport Stream is determined by the constants "PAT_FREQUENCY" and "PMT_FREQUENCY", defined in "liveMedia/MPEG2TransportStreamMultiplexor.cpp". If you decrease these constants, then you will increase the frequency at which the corresponding (PAT or PMT) packets are inserted into the output stream. (As you can see, these constants are actually misnamed. They should have been called "*_PERIOD", not "*_FREQUENCY".) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 6820 bytes Desc: not available URL: From edimartin at gmail.com Wed Jun 19 04:46:41 2013 From: edimartin at gmail.com (Edimartin Martins) Date: Wed, 19 Jun 2013 08:46:41 -0300 Subject: [Live-devel] Fwd: Live555 is not sending the frame In-Reply-To: References: Message-ID: Hi. I need use live555 to send a x264 frame from my Camera to the VLC. I use openCV to get the camera frame and convert from BGR to YUV. I use x264 to convert the frame. But the live555 is not sending the frame. I create a RTSPServer lookupServerMediaSession(char const* streamName){ // //lookUp for the session with the name ServerMediaSession* sms = RTSPServer::lookupServerMediaSession(streamName); if (!sms){ //create the session if this is't exist sms = ServerMediaSession::createNew(envir(), streamName,"send server","sending the camera"); if (sms){ //add a subsession sms->addSubsession( CameraServerMediaSubsession::createNew(envir(),true) ); } } return sms; } The subsession create a FramedSource and VideoRTPSink FramedSource* CameraServerMediaSubsession::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate) { // return new CameraStream(this->envir()); } RTPSink* CameraServerMediaSubsession::createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource){ // return CameraVideoRTPSink::createNew(this->envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); } And I write the CameraStream (FramedSource) using this example: http://www.live555.com/liveMedia/doxygen/html/DeviceSource_8cpp-source.html Here is the code. void CameraStream::doGetNextFrame(){ // if (!isCurrentlyAwaitingData()) return; // we're not ready for the data yet //get the size of the x264 frame unsigned newFrameSize = cameraSize; //create the frame u_int8_t* newFrameDataStart = new u_int8_t[newFrameSize]; //copy the frame data memcpy(newFrameDataStart,camera,cameraSize); //This I found in the example if (newFrameSize > fMaxSize) { fFrameSize = fMaxSize; fNumTruncatedBytes = newFrameSize - fMaxSize; } else { fFrameSize = newFrameSize; } //move the frame to FTO memmove(fTo, newFrameDataStart, fFrameSize); //Inform the reader it's now avaliable FramedSource::afterGetting(this); } The server run the doGetNextFrame function in CameraStream. But the frame is not sent. How can I set the live555 to send the frame? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan_coffey at harvard.edu Wed Jun 19 18:52:09 2013 From: dan_coffey at harvard.edu (Dan Coffey) Date: Wed, 19 Jun 2013 21:52:09 -0400 Subject: [Live-devel] Recommended IP Cameras for OpenRTSP? Message-ID: Hi There, I have been working on a project to record audio/video from IP security cameras where people are giving talks in a room. I have been working with Axis p1354 cameras capturing H.264 + AAC. I have had major issues keeping audio/video in sync. I first tried FFMPEG, then VLC, and finally openRTSP. Does anyone have an IP camera that they could recommend for a project like this (1080p 30fps is ideal). The final destination for the videos is youtube, the problem is that some videos lose sync or are rejected by youtube. I have tried the -y (sometimes causes issues when I try to upload to youtube or transcode with ffmpeg) and I have tried -l (causes all kinds of video artifacts). If I leave out -y, the video is not rejected by youtube but can lose sync over time. Thanks for any advice! Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From xieyongda at gmail.com Wed Jun 19 09:43:33 2013 From: xieyongda at gmail.com (=?GB2312?B?0LvTwLTv?=) Date: Thu, 20 Jun 2013 00:43:33 +0800 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <51C00FF6.1080004@gosniias.ru> References: <51C00FF6.1080004@gosniias.ru> Message-ID: Hmmm, I found that the class "TCPSocketDescribe" in RTPInterface.cpp had been double free sometimes, when it happen, the app crash. 2013/6/18 Andrey > Thanks for the quick reply. However, the error occurs even if the test > code testOnDemandRTSPServer reuseFirstSource set to True. I have not > changed anything in the code, except the reuseFirstSource. The error occurs > on the socket fClientInputSocket of RTSPServer.cpp. Closing the socket > occurs after the call closeSockets () in the destructor ~ > RTSPClientConnection (), respectively, which is called when the session > with the client. The functions of the closeSockets () before closing the > socket is called disableBackgroundHandling (fClientInputSocket). The idea > is all right, and select () function should not be to access a closed > socket. However, after repeated reconnect the client to the server in the > select () function generates an error. The problem arises only when the > true meaning of reuseFirstSource and multiple client reconnects to the > server. Perhaps the problem is disableBackgroundHandling, in any case, the > error is random and can occur as a reconnection with the client, and more > than a hundred. > ______________________________**_________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/**mailman/listinfo/live-devel > -- by:??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From howtofly at gmail.com Wed Jun 19 18:20:44 2013 From: howtofly at gmail.com (Peng) Date: Thu, 20 Jun 2013 09:20:44 +0800 Subject: [Live-devel] New (custom) "REGISTER" command - for advertising a RTSP, stream to a client or proxy server (Ross Finlayson) In-Reply-To: References: Message-ID: <51C258EC.3090709@gmail.com> Hi, Ross. This REGISTER feature sounds quite interesting. Could you explain a bit more about its impact on existing RTSP servers? For example, how does it affect the RTSP state machine? Do we need extra state for it to work? Regards Peng From finlayson at live555.com Wed Jun 19 22:59:14 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Jun 2013 22:59:14 -0700 Subject: [Live-devel] Recommended IP Cameras for OpenRTSP? In-Reply-To: References: Message-ID: <4553428F-390A-452F-A898-71D370DD7667@live555.com> > I have been working on a project to record audio/video from IP security cameras where people are giving talks in a room. > > I have been working with Axis p1354 cameras capturing H.264 + AAC. I have had major issues keeping audio/video in sync. I first tried FFMPEG, then VLC, and finally openRTSP. > > Does anyone have an IP camera that they could recommend for a project like this (1080p 30fps is ideal). The final destination for the videos is youtube, the problem is that some videos lose sync or are rejected by youtube. > > I have tried the -y (sometimes causes issues when I try to upload to youtube or transcode with ffmpeg) and I have tried -l (causes all kinds of video artifacts). If I leave out -y, the video is not rejected by youtube but can lose sync over time. The problem is not really the IP camera, but the ".mp4" file format; it is ill-suited for what we are trying to do here: Record a file that properly represents incoming audio and video frames that are time-stamped. While it's possible that this part of our code could be improved (the code to look at would be the "QuickTimeFileSink" class), the real problem is that the ".mp4" format is not good for recording incoming RTSP/RTP streams like this. The 'Matroska' file format (i.e., ".mkv" files) would be much better for recording timestamped media data like this. A project to support this has been proposed, but has not yet been sufficiently funded - see http://live555.com/funded-projects/live555-mkv.html An alternative approach might be to use VLC - which is not only a media player, but also has transcoding/recording functionality. I.e., what might work is to use VLC to play your stream (from your IP camera, using its "rtsp://" URL), and then transcode the audio/video into an output ".mp4" file. The reason why this might work is that VLC would actually be transcoding (i.e., decoding/reencoding) the audio+video into a new ".mp4" file, rather than just writing the original encoded data to a file - which is what "openRTSP" does. If you try this, however, you'll need to use a VLC mailing list - not this mailing list - for further support... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 19 23:00:30 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Jun 2013 23:00:30 -0700 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: References: <51C00FF6.1080004@gosniias.ru> Message-ID: <7D3D4464-FCC7-472E-85B9-733C53C5FFF9@live555.com> > Hmmm, I found that the class "TCPSocketDescribe" in RTPInterface.cpp had been double free sometimes That sounds good - except that our code doesn't have a class named "TCPSocketDescribe". If you find a specific bug in our code, however (be sure to use the latest version!), please let us know. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 20 00:53:17 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jun 2013 00:53:17 -0700 Subject: [Live-devel] New (custom) "REGISTER" command - for advertising a RTSP, stream to a client or proxy server (Ross Finlayson) In-Reply-To: <51C258EC.3090709@gmail.com> References: <51C258EC.3090709@gmail.com> Message-ID: <05596C67-E201-423D-9989-39A71E22F36C@live555.com> > This REGISTER feature sounds quite interesting. Could you explain a bit more about its impact on existing RTSP servers? It has no impact at all on existing RTSP servers. Existing servers do not handle our new "REGISTER" command, so they'll return a 'Request not understood'-type error should they receive one. The same is also true for LIVE555 RTSP servers. By default, they don't handle the "REGISTER" command either. The only way for a server to handle this command is to subclass "RTSPServer" and reimplement the virtual functions "weImplementREGISTER()" and "implementCmd_REGISTER()". This is what we did for the "RTSPServerWithREGISTERProxying" and "HandlerServerForREGISTERCommand" classes that I mentioned in my email. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xieyongda at gmail.com Thu Jun 20 04:58:53 2013 From: xieyongda at gmail.com (=?GB2312?B?0LvTwLTv?=) Date: Thu, 20 Jun 2013 19:58:53 +0800 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <7D3D4464-FCC7-472E-85B9-733C53C5FFF9@live555.com> References: <51C00FF6.1080004@gosniias.ru> <7D3D4464-FCC7-472E-85B9-733C53C5FFF9@live555.com> Message-ID: It's my fault, I forgot the class name, I checkout the code, class name is SocketDescriptor. Bellow is my app call stack , I don't know why its' deconstruct function has been call twice. #0 0x0000003c954328a5 in raise () from /lib64/libc.so.6 #1 0x0000003c95434085 in abort () from /lib64/libc.so.6 #2 0x000000000047a626 in OnSIGSEGV (signum=11, info=0x7f9a624bb770, ptr=0x7f9a624bb640) at /root/stream/src/../include/OnSegFault.h:107 #3 #4 0x00000000004d4651 in socketHashTable (env=..., createIfNotPresent=1 '\001') at /root/stream/3rd/live555/liveMedia/RTPInterface.cpp:41 #5 0x00000000004d4790 in removeSocketDescription (env=..., sockNum=30) at /root/stream/3rd/live555/liveMedia/RTPInterface.cpp:94 #6 0x00000000004d5289 in SocketDescriptor::~SocketDescriptor (this=0x7f9a54004450, __in_chrg=) at /root/stream/3rd/live555/liveMedia/RTPInterface.cpp:351 #7 0x00000000004d531c in SocketDescriptor::~SocketDescriptor (this=0x7f9a54004450, __in_chrg=) at /root/stream/3rd/live555/liveMedia/RTPInterface.cpp:358 #8 0x00000000004d5522 in SocketDescriptor::tcpReadHandler1 (this=0x7f9a54004450, mask=2) at /root/stream/3rd/live555/liveMedia/RTPInterface.cpp:419 #9 0x00000000004d54a8 in SocketDescriptor::tcpReadHandler (socketDescriptor=0x7f9a54004450, mask=2) at /root/stream/3rd/live555/liveMedia/RTPInterface.cpp:398 #10 0x00000000005000a5 in BasicTaskScheduler::SingleStep (this=0x1c285b0, maxDelayTime=0) at /root/stream/3rd/live555/BasicUsageEnvironment/BasicTaskScheduler.cpp:162 #11 0x00000000004fea54 in BasicTaskScheduler0::doEventLoop (this=0x1c285b0, watchVariable=0x1c26ba8 "") at /root/stream/3rd/live555/BasicUsageEnvironment/BasicTaskScheduler0.cpp:80 2013/6/20 Ross Finlayson > Hmmm, I found that the class "TCPSocketDescribe" in RTPInterface.cpp had > been double free sometimes > > > That sounds good - except that our code doesn't have a class named > "TCPSocketDescribe". > > If you find a specific bug in our code, however (be sure to use the latest > version!), please let us know. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -- by:??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 20 07:11:26 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jun 2013 07:11:26 -0700 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: References: <51C00FF6.1080004@gosniias.ru> <7D3D4464-FCC7-472E-85B9-733C53C5FFF9@live555.com> Message-ID: <6C72E272-09B3-4F5A-8896-BF87002F5F69@live555.com> > Bellow is my app call stack This call stack tells me that you are *not* using the latest version of the code (because, in the latest version of the code, the "SocketDescriptor" object is deleted from "tcpReadHandler()", not from "tcpReadHandler1()". A bug in this code was fixed on April 30th - so please upgrade to the latest version of the code, as you were asked. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Jun 20 21:50:24 2013 From: warren at etr-usa.com (Warren Young) Date: Thu, 20 Jun 2013 22:50:24 -0600 Subject: [Live-devel] Recommended IP Cameras for OpenRTSP? In-Reply-To: <4553428F-390A-452F-A898-71D370DD7667@live555.com> References: <4553428F-390A-452F-A898-71D370DD7667@live555.com> Message-ID: <51C3DB90.6030602@etr-usa.com> On 6/19/2013 23:59, Ross Finlayson wrote: > A project to support this > has been proposed, but has not yet been sufficiently funded - see > http://live555.com/funded-projects/live555-mkv.html Would you please put a goal thermometer[*] on these pages? I think you could get certain interested parties to finish funding a project if it had gotten close to its target, and the delta were within discretionary funding limits. :) [*] http://www.entropyfarm.org/software/thermo/ From chris at gotowti.com Fri Jun 21 17:15:27 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Fri, 21 Jun 2013 17:15:27 -0700 Subject: [Live-devel] Handle carriage return/line feed in base64Decode Message-ID: <017101ce6edd$9a006cf0$ce0146d0$@com> Hi Ross, I recently came across a client who sends our LIVE555 based RTSP server an HTTP message with a base64 encoded RTSP command that contains CR/LF. It seems fairly standard for a base64 decoder to support CR/LF, at least on 4 char boundaries, so I wrote up a patch to base64Decode to allow this. Then I discovered how the fragmented base64 message reading is implemented in RTSPServer and determined that the fix would not be so simple. I have pasted the relevant part of the RTSP conversation, for your information. Note that the client (not under my control) is using a very old version of LIVE555, but that is irrelevant to the test being performed, which is that the server supports base64 data with CR/LF. accept()ed connection from 192.168.2.100 RTSPClientConnection[0x5cc908]::handleRequestBytes() read 212 new bytes:GET /swVideo HTTP/1.0 User-Agent: ONVIF Filter (LIVE555 Streaming Media v2009.11.27) x-sessioncookie: 0695c54a1abd2adfb783b89 Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache parseRTSPRequestString() failed; checking now for HTTP commands (for RTSP-over-HTTP tunneling)... parseHTTPRequestString() succeeded, returning cmdName "GET", urlSuffix "swVideo", sessionCookie "0695c54a1abd2adfb783b89", acceptStr "application/x-rtsp-tunnelled" Handled HTTP "GET" request (client output socket: 31) sending response: HTTP/1.0 200 OK Date: Thu, 19 Aug 1982 18:30:00 GMT Cache-Control: no-cache Pragma: no-cache Content-Type: application/x-rtsp-tunnelled accept()ed connection from 192.168.2.100 RTSPClientConnection[0x5d1788]::handleRequestBytes() read 281 new bytes:POST /swVideo HTTP/1.0 User-Agent: ONVIF Filter (LIVE555 Streaming Media v2009.11.27) x-sessioncookie: 0695c54a1abd2adfb783b89 Content-Type: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Content-Length: 32767 Expires: Sun, 9 Jan 1972 00:00:00 GMT ---------- Below you can see that the base64 input has line breaks, which the decoder does not handle. ---------- parseRTSPRequestString() failed; checking now for HTTP commands (for RTSP-over-HTTP tunneling)... parseHTTPRequestString() succeeded, returning cmdName "POST", urlSuffix "swVideo", sessionCookie "0695c54a1abd2adfb783b89", acceptStr "" Handled HTTP "POST" request (client input socket: 35) RTSPClientConnection[0x5cc908]::handleRequestBytes() read 210 new bytes:REVTQ1JJQkUgcnRzcDovLzE5Mi4xNjguMi42Mjo4NTU0L3N3VmlkZW8gUlRTUC8x LjANCkNTZXE6IDANCkFjY2VwdDogYXBwbGljYXRpb24vc2RwDQpVc2VyLUFnZW50 OiBPTlZJRiBGaWx0ZXIgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDA5LjEx LjI3KQ0KDQo= Base64-decoded 208 input bytes into 156 new bytes:DESCRIBE rtsp://192.168.2.62:8554/swVideo RTSP/1??56W??66WC??6F???6G?W6W"?vV?@: ONVIF Filter (LIVE555 Streaming Media v2009.11?#r?? Thanks, Chris Richardson WTI -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 23 16:37:32 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 23 Jun 2013 16:37:32 -0700 Subject: [Live-devel] Handle carriage return/line feed in base64Decode In-Reply-To: <017101ce6edd$9a006cf0$ce0146d0$@com> References: <017101ce6edd$9a006cf0$ce0146d0$@com> Message-ID: <16E86A2D-58E8-43E7-A784-A6672DF8F502@live555.com> > I recently came across a client who sends our LIVE555 based RTSP server an HTTP message with a base64 encoded RTSP command that contains CR/LF. It seems fairly standard for a base64 decoder to support CR/LF, at least on 4 char boundaries, so I wrote up a patch to base64Decode to allow this. Then I discovered how the fragmented base64 message reading is implemented in RTSPServer and determined that the fix would not be so simple. Rather than put CR/LF (or other whitespace) removal inside the Base-64 decoding routine, we can just add a whitespace-removing pass to the "RTSPServer" code, before we call "base64Decode()". I'll add this change to the next release of the code. > Note that the client (not under my control) is using a very old version of LIVE555, but that is irrelevant to the test being performed Yes, though note that - in at least one respect - this client is under your control (or perhaps more accurately, under *my* control). Under the terms of the LGPL, the developers of this client must - when requested by you (or whoever owns the client) - update it to use the latest version of the LIVE555 code, or else provide a way for the owner to update it themself. If anyone is using an application that is using an old version of the LIVE555 code, they should ask the application's developer to upgrade it. If they refuse (or ignore) your request, let me know, and I'll get in touch with them, reminding them of their legal obligations. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xieyongda at gmail.com Sat Jun 22 02:49:53 2013 From: xieyongda at gmail.com (=?GB2312?B?0LvTwLTv?=) Date: Sat, 22 Jun 2013 17:49:53 +0800 Subject: [Live-devel] Is there any plan to suport "ANNOUNCE" command? Message-ID: If any one want to publis an exist stream, it may be helpful. Thanks -- by:crazyevent -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 24 00:46:26 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Jun 2013 00:46:26 -0700 Subject: [Live-devel] Is there any plan to suport "ANNOUNCE" command? In-Reply-To: References: Message-ID: "RTSPClient" has a member function that allows clients to send RTSP "ANNOUNCE" commands. However, our servers do not (and probably never will) handle incoming "ANNOUNCE" commands - because it was a poorly designed (and barely and inconsistently implemented) feature of the protocol. (Note that it was removed from the proposed "RTSP 2.0" upgrade of the protocol, for this reason.) There's no need to 'inject' a stream's SDP description (nor stream data itself) into a server, because we already have a perfectly good mechanism for getting stream information and data - from a "rtsp://" URL, via the usual RTSP "DESCRIBE" command. A much better mechanism is just to 'inject' a "rtsp://" URL - and this is what our new "REGISTER" command does. You should use this instead. See http://lists.live555.com/pipermail/live-devel/2013-June/017112.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatafaraco at gmail.com Mon Jun 24 11:24:47 2013 From: renatafaraco at gmail.com (Renata) Date: Mon, 24 Jun 2013 15:24:47 -0300 Subject: [Live-devel] Synchronization with Pelco Sarix Cameras Message-ID: Hello, I made a RTSP Client to receive a RTSP stream from a camera Pelco Sarix. This stream has been saved in a MediaSink configured to have the same parameters (frames per second, among others) of the stream. But, for each 1 hour recorded I get a 1:03h video file.Is there anything I can do to get and recording the stream at the same velocity? Thanks for your attention. Renata Faraco Cunha -------------- next part -------------- An HTML attachment was scrubbed... URL: From cohenguy1 at yahoo.com Mon Jun 24 13:26:14 2013 From: cohenguy1 at yahoo.com (Guy Cohen) Date: Mon, 24 Jun 2013 13:26:14 -0700 (PDT) Subject: [Live-devel] Streaming H.264 avc Message-ID: <1372105574.10916.YahooMailNeo@web125901.mail.ne1.yahoo.com> Hi The file extension is indeed mpg. I have 3 streams in it:? One of them is mpeg audio, another audio stream of mpeg2-ps (which I suspect is corrupted) and a video stream of h264ES. Can testOnDemandRTSPServer work with this? How I'm supposed to stream this kind of media? Can I stream only the h264 video? when I ran the?testOnDemandRTSPServer?the image I get from the rtsp url is corrupted. Thanks, Guy. >? > I ran the testOnDemandRTSPServer, >? > but when I stream the h.264 movie and play it with vlc, the image is corrupted. > The format of the video is mpg. >? > I don't know where I went wrong... Probably the filename (extension) that you used. Is your file a H.264 Video Elementary Stream file?? If so, use a ".264" filename extension (e.g., "test.264" for streaming by "testOnDemandRTSPServer"). However, you said that "The format of your video is mpg".? I don't know that that means, but the ".mpg" filename extension is used for MPEG-1 or 2 Audio+Video Program Stream files, which is almost certainly not what you want.? So don't call your file "test.mpg". If you are sure that your file is a H.264 Video Elementary Stream file, then please put the file on a publically-accessible web (or FTP) server, and post the URL (not the file itself) to the "live-devel" mailing list, and we'll take a look at it, to see if we can figure out what's wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 24 17:58:58 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Jun 2013 17:58:58 -0700 Subject: [Live-devel] Synchronization with Pelco Sarix Cameras In-Reply-To: References: Message-ID: <5F4038DA-BB21-4DDF-B05F-331841248FBE@live555.com> > I made a RTSP Client to receive a RTSP stream from a camera Pelco Sarix. This stream has been saved in a MediaSink configured to have the same parameters (frames per second, among others) of the stream. But, for each 1 hour recorded I get a 1:03h video file.Is there anything I can do to get and recording the stream at the same velocity? Without knowing the details of what your "MediaSink" subclass looks like, it's hard to answer this question. However, you should use the 'presentation time' (that you get along with each received frame) to figure out when each frame should be played. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 24 18:00:44 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Jun 2013 18:00:44 -0700 Subject: [Live-devel] Streaming H.264 avc In-Reply-To: <1372105574.10916.YahooMailNeo@web125901.mail.ne1.yahoo.com> References: <1372105574.10916.YahooMailNeo@web125901.mail.ne1.yahoo.com> Message-ID: <3F698B8D-6A0A-4561-9BFA-34DF012AF1CB@live555.com> > The file extension is indeed mpg. I have 3 streams in it: > One of them is mpeg audio, another audio stream of mpeg2-ps (which I suspect is corrupted) and a video stream of h264ES. > > Can testOnDemandRTSPServer work with this? I think so. But yet again: > Please put the file on a publically-accessible web (or FTP) server, and post the URL (not the file itself) to the "live-devel" mailing list, and we'll take a look at it, to see if we can figure out what's wrong. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaobing at jriver.com Tue Jun 25 07:59:53 2013 From: yaobing at jriver.com (Yaobing Deng) Date: Tue, 25 Jun 2013 09:59:53 -0500 Subject: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime Message-ID: <51C9B069.8020202@jriver.com> Hi, I am using the RTSP client of Live555 in my application. The purpose is to support CableCARD tuners. I got it working for some devices (such as Ceton InfiniTV) but encountered a problem with SiliconDust's HDHomeRun PRIME. What I found out (and also confirmed by SiliconDust support) is that the device sends a value of 96 for payload type in the SDP description, like the following, v=0 t=0 0 a=type:broadcast a=recvonly m=video 0 RTP/AVP 96 a=rtpmap:96 MP2T/27000000 but when the actual video is streamed, the type is of value 33. In MultiFramedRTPSource.cpp, such packets are ignored: void MultiFramedRTPSource::networkReadHandler1() { ... // Check the Payload Type. if ((unsigned char)((rtpHdr&0x007F0000)>>16) != rtpPayloadFormat()) { break; } ... } I have not received an explanation from SiliconDust on why this happens, but I would like to ask you whether there should be a way to accommodate such situation instead of rejecting the packets outright. Can this be fixed/worked around? Thanks for listening. Yaobing From finlayson at live555.com Tue Jun 25 12:38:41 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 25 Jun 2013 12:38:41 -0700 Subject: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime In-Reply-To: <51C9B069.8020202@jriver.com> References: <51C9B069.8020202@jriver.com> Message-ID: <659AE46F-08B4-43AA-86DD-CBD80E2C234B@live555.com> > I am using the RTSP client of Live555 in my application. The purpose is to support CableCARD tuners. I got it working for some devices (such as Ceton InfiniTV) but encountered a problem with SiliconDust's HDHomeRun PRIME. What I found out (and also confirmed by SiliconDust support) is that the device sends a value of 96 for payload type in the SDP description, like the following, > > v=0 > t=0 0 > a=type:broadcast > a=recvonly > m=video 0 RTP/AVP 96 > a=rtpmap:96 MP2T/27000000 > > but when the actual video is streamed, the type is of value 33. This is clearly an error in the server (the "SiliconDust's HDHomeRun PRIME"). It is advertising that its RTP packets are using RTP payload format code 96 - which is wrong - and using a RTP timestamp frequency of 27000000 - which is probably also wrong. (MPEG Transport Stream packets are usually streamed in RTP with a standard RTP timestamp frequency of 90000.) The server needs to be fixed, because it is advertising a stream that it is not providing. Instead of these SDP lines: m=video 0 RTP/AVP 96 a=rtpmap:96 MP2T/27000000 The server should be fixed so that it sends just: m=video 0 RTP/AVP 33 because "33" is a static RTP payload format code, defined specifically to mean: streaming MPEG Transport Stream data at frequency 90000. Or, if the server really is using a nonstandard RTP timestamp frequency of 27000000 (which is unlikely, but conceivable), then it should send: m=video 0 RTP/AVP 33/27000000 Please contact "SiliconDust" to tell them to fix their server, and suggest that - in the future - they use our free RTSP client applications "testRTSPClient" and "openRTSP" to test their RTSP implementation. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xieyongda at gmail.com Tue Jun 25 02:58:08 2013 From: xieyongda at gmail.com (=?GB2312?B?0LvTwLTv?=) Date: Tue, 25 Jun 2013 17:58:08 +0800 Subject: [Live-devel] live555 taskSchedule thread was hung Message-ID: As my testing, the function RTPInterface::sendRTPorRTCPPacketOverTCP may hung taskSchedule's thread, I found it was at source code line 307, and I modify it from " if (!sendDataOverTCP(socketNum, packet, packetSize, True)) break;" to "if (!sendDataOverTCP(socketNum, packet, packetSize, False)) break;" My test client is ffplay. I guest the reason is that nonblock send() call was failed, and then set this client socket into blocking mode and resend, but ffplay read data may return error and it will retry, so ffplay's receive buffer was full, and our send() was block; Thanks -- by:crazyevent -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 25 17:32:33 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 25 Jun 2013 17:32:33 -0700 Subject: [Live-devel] live555 taskSchedule thread was hung In-Reply-To: References: Message-ID: The existing code is correct. The reason for this code is to ensure that sending a (RTP or RTCP) packet over a TCP connection - which involves two separate writes: one for a header; another for the packet data itself - occurs as an atomic operation. I.e., we want either neither of the writes to succeed, or both of them to succeed. If the write of the header were to succeed, but the subsequent write of the packet data were to fail, then you'd end up with invalid data being sent (and thus received) over the TCP connection. Your write operation is blocking because your stream is - at least temporarily - exceeding the capacity of your network. To avoid this, you need a slower stream, or a faster network. A reminder - yet again - that RTP/RTCP-over-TCP should be used *only* if you have a firewall that is blocking UDP packets. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From raja.dm at hcl.com Tue Jun 25 22:04:31 2013 From: raja.dm at hcl.com (Rajadeepan Murugesan, ERS, HCLTech) Date: Wed, 26 Jun 2013 05:04:31 +0000 Subject: [Live-devel] (no subject) Message-ID: <102889FA8FBE20499393108BB0373BCE01543A9A@chn-hclt-mbs06.HCLT.CORP.HCL.IN> Hi, I downloaded the entire source code (usage environment,...testprogs,etc) and builded them. An .exe file is generated for each application in test progs folder. Now how to test " testMPEG1OR2VideoReceiver".exe . Please provide the details for testing the application as how to give input stream to the application and to check whether the input stream is given as output. Please help me... Regards , Boss ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 26 00:15:50 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Jun 2013 00:15:50 -0700 Subject: [Live-devel] (no subject) In-Reply-To: <102889FA8FBE20499393108BB0373BCE01543A9A@chn-hclt-mbs06.HCLT.CORP.HCL.IN> References: <102889FA8FBE20499393108BB0373BCE01543A9A@chn-hclt-mbs06.HCLT.CORP.HCL.IN> Message-ID: > I downloaded the entire source code (usage environment,?testprogs,etc) and builded them. An .exe file is generated for each application in test progs folder. Now how to test ? testMPEG1OR2VideoReceiver?.exe . Please provide the details for testing the application as how to give input stream to the application and to check whether the input stream is given as output. Please help me? I assume that you've read http://www.live555.com/liveMedia/#testProgs The "testMPEG1or2VideoReceiver" demo application shows how to receive a MPEG-1 or 2 Video RTP multicast stream. You can demonstrate this using the "testMPEG1or2VideoStreamer" demo application, which reads a MPEG-1 or 2 Video Elementary Stream file - named "test.mpg" - and streams it via RTP multicast. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From raja.dm at hcl.com Wed Jun 26 02:19:30 2013 From: raja.dm at hcl.com (Rajadeepan Murugesan, ERS, HCLTech) Date: Wed, 26 Jun 2013 09:19:30 +0000 Subject: [Live-devel] REG: USING "testMPEG1OR2VideoReceiver" Application Message-ID: <102889FA8FBE20499393108BB0373BCE01543B3E@chn-hclt-mbs06.HCLT.CORP.HCL.IN> Hi, Actually, I need to read RTP/RTCP (video) stream in a network by a device that is connected to that network . Already the video is being streamed by some other device in the network. I am using the "testMPEG1or2VideoReceiver".exe for reading the stream. I have installed this "testMPEG1or2VideoReceiver.exe" in the device which needs to read the stream. But it is not working. Please help me as how to use this application in this scenario. I changed the source address and port number in the code and built it. Do I need to make any more changes in the code ? if yes, please let me know.. Regards , Rajadeepan M Lead Engineer HCL Technologies Ltd. No.184, NSK Road, Vadapalani, Chennai -26 Tel: +91-44 2372 8366 / 42004700 Extn. (2329) M-9994325735 www.hcl.com ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 26 02:36:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Jun 2013 02:36:35 -0700 Subject: [Live-devel] REG: USING "testMPEG1OR2VideoReceiver" Application In-Reply-To: <102889FA8FBE20499393108BB0373BCE01543B3E@chn-hclt-mbs06.HCLT.CORP.HCL.IN> References: <102889FA8FBE20499393108BB0373BCE01543B3E@chn-hclt-mbs06.HCLT.CORP.HCL.IN> Message-ID: <2CE5ADF2-0BDB-4A2A-B95B-6D2CB7B8FB42@live555.com> > Actually, I need to read RTP/RTCP (video) stream in a network by a device that is connected to that network . Is the RTP/RTCP stream accessible via RTSP (i.e., from a "rtsp://" URL)? If so, use our "openRTSP" client application. If not, then is the stream being send via multicast, or unicast? Does it have a SDP description? What RTP payload format(s) (i.e., codec(s)) does the stream use? In other words, we would need to know a *lot* more about this stream until we could tell you how to receive it using our software. In any case, because you appear to be somewhat 'out of your depth' here, I suggest that you try to learn a lot more about our software - and about RTP in general - first. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaobing at jriver.com Wed Jun 26 08:24:51 2013 From: yaobing at jriver.com (Yaobing Deng) Date: Wed, 26 Jun 2013 10:24:51 -0500 Subject: [Live-devel] live-devel Digest, Vol 116, Issue 18 In-Reply-To: References: Message-ID: <51CB07C3.3030200@jriver.com> On 6/26/2013 2:15 AM, live-devel-request at ns.live555.com wrote: > Message: 2 > Date: Tue, 25 Jun 2013 12:38:41 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime > Message-ID: <659AE46F-08B4-43AA-86DD-CBD80E2C234B at live555.com> > Content-Type: text/plain; charset="us-ascii" > >> I am using the RTSP client of Live555 in my application. The purpose is to support CableCARD tuners. I got it working for some devices (such as Ceton InfiniTV) but encountered a problem with SiliconDust's HDHomeRun PRIME. What I found out (and also confirmed by SiliconDust support) is that the device sends a value of 96 for payload type in the SDP description, like the following, >> >> v=0 >> t=0 0 >> a=type:broadcast >> a=recvonly >> m=video 0 RTP/AVP 96 >> a=rtpmap:96 MP2T/27000000 >> >> but when the actual video is streamed, the type is of value 33. > This is clearly an error in the server (the "SiliconDust's HDHomeRun PRIME"). It is advertising that its RTP packets are using RTP payload format code 96 - which is wrong - and using a RTP timestamp frequency of 27000000 - which is probably also wrong. (MPEG Transport Stream packets are usually streamed in RTP with a standard RTP timestamp frequency of 90000.) > > The server needs to be fixed, because it is advertising a stream that it is not providing. > > Instead of these SDP lines: > m=video 0 RTP/AVP 96 > a=rtpmap:96 MP2T/27000000 > The server should be fixed so that it sends just: > m=video 0 RTP/AVP 33 > because "33" is a static RTP payload format code, defined specifically to mean: streaming MPEG Transport Stream data at frequency 90000. > Or, if the server really is using a nonstandard RTP timestamp frequency of 27000000 (which is unlikely, but conceivable), then it should send: > m=video 0 RTP/AVP 33/27000000 > > Please contact "SiliconDust" to tell them to fix their server, and suggest that - in the future - they use our free RTSP client applications "testRTSPClient" and "openRTSP" to test their RTSP implementation. Thanks for the reply. I am contacting SiliconDust, and hoping they will fix the problem soon. Meanwhile, in order to make their device work in our application (JRiver Media Center), we are temporarily ignoring the payload type discrepancy, in the following way, until SiliconDust fixes the problem. We change this block // Check the Payload Type. if ((unsigned char)((rtpHdr&0x007F0000)>>16) != rtpPayloadFormat()) { break; } to this // Check the Payload Type. // Kludge - HDHomeRun Prime advertises the value 96, but sends the value 33 if ((unsigned char)((rtpHdr&0x007F0000)>>16) != rtpPayloadFormat() && ((unsigned char)((rtpHdr&0x007F0000)>>16) != 33 || rtpPayloadFormat() != 96)) { break; } inside function MultiFramedRTPSource::networkReadHandler1(). Thanks again. Yaobing Deng JRiver From finlayson at live555.com Wed Jun 26 08:45:45 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Jun 2013 08:45:45 -0700 Subject: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime In-Reply-To: <51CB07C3.3030200@jriver.com> References: <51CB07C3.3030200@jriver.com> Message-ID: <08A7654C-7204-42AF-85A7-E616EE010B37@live555.com> On Jun 26, 2013, at 8:24 AM, Yaobing Deng wrote: > Meanwhile, in order to make their device work in our application (JRiver Media Center), we are temporarily ignoring the payload type discrepancy, in the following way, until SiliconDust fixes the problem. Remember that under the terms of the (L)GPL, you are therefore legally required to make your 'kludge' available to all customers of your application. A much better solution, therefore, is to get 'SiliconDust' to fix their buggy, non-standards-compliant hardware (e.g., via a firmware upgrade). Then, you won't need to make (and therefore won't need to distribute with your own product) any changes to the "LIVE555 Streaming Media" code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ps. A reminder to everyone: If you're replying to a mailing list 'Digest' message, please fix the "Subject:" line of your response. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaobing at jriver.com Wed Jun 26 09:14:16 2013 From: yaobing at jriver.com (Yaobing Deng) Date: Wed, 26 Jun 2013 11:14:16 -0500 Subject: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime In-Reply-To: <51C9B069.8020202@jriver.com> References: <51C9B069.8020202@jriver.com> Message-ID: <51CB1358.4040402@jriver.com> > On Jun 26, 2013, at 8:24 AM, Yaobing Deng > wrote: >>/Meanwhile, in order to make their device work in our application (JRiver Media Center), we are temporarily ignoring the payload type >> discrepancy, in the following way, until SiliconDust fixes the problem. > /> Remember that under the terms of the (L)GPL, you are therefore legally required to make your 'kludge' available to all customers of your > application. A much better solution, therefore, is to get 'SiliconDust' to fix their buggy, non-standards-compliant hardware (e.g., via a firmware > upgrade). Then, you won't need to make (and therefore won't need to distribute with your own product) any changes to the "LIVE555 > Streaming > Media" code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ Thanks for the reminder about the GPL. I do have that in mind when I replied your last message (and sorry for forgetting to fix the subject line). Would it not be sufficient by making my changes public on this developer mailing list (as I attempted in my previous reply)? We change this block // Check the Payload Type. if ((unsigned char)((rtpHdr&0x007F0000)>>16) != rtpPayloadFormat()) { break; } to this // Check the Payload Type. // Kludge - HDHomeRun Prime advertises the value 96, but sends the value 33 if ((unsigned char)((rtpHdr&0x007F0000)>>16) != rtpPayloadFormat() && ((unsigned char)((rtpHdr&0x007F0000)>>16) != 33 || rtpPayloadFormat() != 96)) { break; } inside function MultiFramedRTPSource::networkReadHandler1(). -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 26 10:16:54 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Jun 2013 10:16:54 -0700 Subject: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime In-Reply-To: <51CB1358.4040402@jriver.com> References: <51C9B069.8020202@jriver.com> <51CB1358.4040402@jriver.com> Message-ID: > Thanks for the reminder about the GPL. I do have that in mind when I replied your last message (and sorry for forgetting to fix the subject line). Would it not be sufficient by making my changes public on this developer mailing list No - because few (if any) of your customers subscribe to this mailing list. You could, however, put your modifications on your product's web site. For more about the LGPL and your obligations (and this applies to everyone who uses the "LIVE555 Streaming Media" software), see: http://www.live555.com/liveMedia/faq.html#copyright-and-license Once again, by far the simplest (and best solution) is just to get "SiliconBeach" to fix their hardware. (If anyone from "SiliconBeach" wants to get in touch with me, I'd be happy to work with them to help make their products standards-compliant.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zammargu at marvell.com Wed Jun 26 18:32:03 2013 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Wed, 26 Jun 2013 18:32:03 -0700 Subject: [Live-devel] Instrumentation to detect packet loss in my application Message-ID: Hello, The application I am running is loosing packets. This application runs a server and a client. On the server application an RTP server is running and on the client application an RTP client is running. I am trying to implement the live555 code to make sure that all packets that are sent from the RTP server are arriving to the RTP client. It looks from your documentation that live555 doesn't drop any packets, I would like to instrument live555 to make sure that the (most) of the packets are arriving at destination and that probably the video dropping that I see is due to the loss in the network layer. In RTPInterface.cpp there is a function called sendPacket. I have added a printf there to detect the packet sent and its size. I would like to "recover" the same packet on the client side. Can you tell me what function does that on the client side? Doing that would permit me to find out the packets that were lost. Can you please help? Thanks, -Zahira From finlayson at live555.com Wed Jun 26 22:46:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Jun 2013 22:46:07 -0700 Subject: [Live-devel] Instrumentation to detect packet loss in my application In-Reply-To: References: Message-ID: <5F2D540A-1A16-4C9C-90D2-945D3EB6F9A4@live555.com> > The application I am running is loosing packets. This application runs a server and a client. On the server application an RTP server is running and on the client application an RTP client is running. I am trying to implement the live555 code to make sure that all packets that are sent from the RTP server are arriving to the RTP client. It looks from your documentation that live555 doesn't drop any packets That's correct. I assume you've read http://www.live555.com/liveMedia/faq.html#packet-loss > In RTPInterface.cpp there is a function called sendPacket. I have added a printf there to detect the packet sent and its size. I would like to "recover" the same packet on the client side. Can you tell me what function does that on the client side? "RTPInterface::handleRead()" Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0574119 at 163.com Wed Jun 26 18:37:19 2013 From: 0574119 at 163.com (LiuGaoPing) Date: Thu, 27 Jun 2013 09:37:19 +0800 (CST) Subject: [Live-devel] The option '-R' About openRTSP Message-ID: <54d57e25.2483.13f8347100e.Coremail.0574119@163.com> Hi, How are you! We are a green hand?and very interested in openRTSP. We have downloaded the resource of the openRTSP from the website which is named http://www.live555.com/openRTSP/#support?. Then we have discoveried the ?-R? option in command-line options, and according to the explanation documents this option is used instead of a "rtsp://" URL. However, when we run this program ,the ?-R? option can not be used. In addition, we can not find the way to solve this problem from the source code we have downloaded . So we want to have an idea of whether this option can be used, and you can provide some material concered. Thanks! Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Thu Jun 27 00:24:48 2013 From: ashvyrkin at gosniias.ru (Andrey) Date: Thu, 27 Jun 2013 11:24:48 +0400 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <51C00FF6.1080004@gosniias.ru> References: <51C00FF6.1080004@gosniias.ru> Message-ID: <51CBE8C0.3040307@gosniias.ru> Hi, Ross. I was able to simulate error WINSOCK 10038. To do this, RTSP client must ask the server to send the stream. Accordingly, you should set REQUEST_STREAMING_OVER_TCP to True. Then you need to properly shut down the client, without sending the command TEARDOWN. Maybe a few times. And the next time the client connects, the server returns an error when you call select(). The error occurs on the client socket and the socket until it actually closes, but then again entered into the table socket, then an error occurs. After that there is only a few iterations SingleStep(), and then the handler of this problem socket is removed from the table and error in the select() no longer occurs. I would also like to draw attention to some of the code for the withdrawal of additional debugging information in the SingleStep(). In lines .......... fprintf(stderr, "socket numbers used in the select() call:"); for (int i = 0; i < 100; ++i) { .......... i less than a hundred, but the windows usually have handles more than 100 sets, so it's best to put 10000. This is my log: create socket from socket() num: 300 assignHandler socket num: 300 create socket from socket() num: 288 assignHandler socket num: 288 (We use port 80 for optional RTSP-over-HTTP tunneling.) [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Got a SDP description: v=0 o=- 1339027130613809 1339027130613809 IN IP4 192.168.33.132 s=Media Presentation e=NONE b=AS:50000 t=0 0 a=control:rtsp://192.168.33.132/onvif-media/media.amp?profile=quality_h264&sessi ontimeout=60&streamtype=unicast a=range:npt=0.000000- m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50000 a=framerate:30.0 a=transform:1,0,0;0,1,0;0,0,1 a=control:rtsp://192.168.33.132/onvif-media/media.amp/trackID=1?profile=quality_ h264&sessiontimeout=60&streamtype=unicast a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; profile-level-id=420029; sprop-parameter-sets=Z0 IAKeKQFAZ2AtwEBAaQeJEV,aM48gA== [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Initiated the "video/H264" subsession (client ports 58416-58417) [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Set up the "video/H264" su bsession (client ports 58416-58417) [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Created a data sink for th e "video/H264" subsession [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Started playing session... create new socket from accept() socket num: 532 createNewClientConnection socket num: 532 assignHandler socket num: 532 create new socket from accept() socket num: 520 createNewClientConnection socket num: 520 assignHandler socket num: 520 create socket from socket() num: 524 closeSocket socket num: 524 create socket from socket() num: 960 closeSocket socket num: 960 create socket from socket() num: 928 create socket from socket() num: 924 assignHandler socket num: 924 assignHandler socket num: 520 clearHandler socket num: 924 assignHandler socket num: 924 clearHandler socket num: 924 closeSocket socket num: 928 closeSocket socket num: 924 clearHandler socket num: 520 assignHandler socket num: 520 clearHandler socket num: 520 closeSocket fClientInputSocket num: 520 create new socket from accept() socket num: 520 createNewClientConnection socket num: 520 assignHandler socket num: 520 create socket from socket() num: 584 create socket from socket() num: 588 assignHandler socket num: 588 assignHandler socket num: 520 clearHandler socket num: 588 assignHandler socket num: 588 clearHandler socket num: 588 closeSocket socket num: 584 closeSocket socket num: 588 clearHandler socket num: 520 assignHandler socket num: 520 clearHandler socket num: 520 closeSocket fClientInputSocket num: 520 create new socket from accept() socket num: 520 createNewClientConnection socket num: 520 assignHandler socket num: 520 create socket from socket() num: 640 create socket from socket() num: 1112 assignHandler socket num: 1112 assignHandler socket num: 520 clearHandler socket num: 1112 assignHandler socket num: 1112 clearHandler socket num: 520 clearHandler socket num: 520 closeSocket fClientInputSocket num: 520 create new socket from accept() socket num: 768 createNewClientConnection socket num: 768 assignHandler socket num: 768 assignHandler socket num: 768 clearHandler socket num: 1112 assignHandler socket num: 1112 assignHandler socket num: 520 BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 300(r) 520(re) 532(re) 768(re) 1112(r) WinSock error 10038 BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 300(r) 520(re) 532(re) 768(re) 1112(r) WinSock error 10038 BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 300(r) 520(re) 532(re) 768(re) 1112(r) WinSock error 10038 BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 300(r) 520(re) 532(re) 768(re) 1112(r) WinSock error 10038 clearHandler socket num: 520 clearHandler socket num: 768 assignHandler socket num: 768 clearHandler socket num: 768 closeSocket fClientInputSocket num: 768 create new socket from accept() socket num: 768 createNewClientConnection socket num: 768 assignHandler socket num: 768 assignHandler socket num: 768 clearHandler socket num: 1112 assignHandler socket num: 1112 From ashvyrkin at gosniias.ru Thu Jun 27 00:36:52 2013 From: ashvyrkin at gosniias.ru (Andrey) Date: Thu, 27 Jun 2013 11:36:52 +0400 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <51CBE8C0.3040307@gosniias.ru> References: <51C00FF6.1080004@gosniias.ru> <51CBE8C0.3040307@gosniias.ru> Message-ID: <51CBEB94.6000708@gosniias.ru> It is important to note that the error occurs on the socket fClientInputSocket and the socket when using the TCP, for UDP is not an issue. 27.06.2013 11:24, Andrey ?????: > Hi, Ross. I was able to simulate error WINSOCK 10038. To do this, RTSP > client must ask the server to send the stream. Accordingly, you should > set REQUEST_STREAMING_OVER_TCP to True. Then you need to properly shut > down the client, without sending the command TEARDOWN. Maybe a few > times. And the next time the client connects, the server returns an > error when you call select(). The error occurs on the client socket > and the socket until it actually closes, but then again entered into > the table socket, then an error occurs. After that there is only a few > iterations SingleStep(), and then the handler of this problem socket > is removed from the table and error in the select() no longer occurs. > I would also like to draw attention to some of the code for the > withdrawal of additional debugging information in the SingleStep(). In > lines > .......... > fprintf(stderr, "socket numbers used in the select() call:"); > for (int i = 0; i < 100; ++i) { > .......... > i less than a hundred, but the windows usually have handles more than > 100 sets, so it's best to put 10000. > > > This is my log: > > create socket from socket() num: 300 > assignHandler socket num: 300 > create socket from socket() num: 288 > assignHandler socket num: 288 > > (We use port 80 for optional RTSP-over-HTTP tunneling.) > [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Got a SDP > description: > v=0 > o=- 1339027130613809 1339027130613809 IN IP4 192.168.33.132 > s=Media Presentation > e=NONE > b=AS:50000 > t=0 0 > a=control:rtsp://192.168.33.132/onvif-media/media.amp?profile=quality_h264&sessi > > ontimeout=60&streamtype=unicast > a=range:npt=0.000000- > m=video 0 RTP/AVP 96 > c=IN IP4 0.0.0.0 > b=AS:50000 > a=framerate:30.0 > a=transform:1,0,0;0,1,0;0,0,1 > a=control:rtsp://192.168.33.132/onvif-media/media.amp/trackID=1?profile=quality_ > > h264&sessiontimeout=60&streamtype=unicast > a=rtpmap:96 H264/90000 > a=fmtp:96 packetization-mode=1; profile-level-id=420029; > sprop-parameter-sets=Z0 > IAKeKQFAZ2AtwEBAaQeJEV,aM48gA== > > [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Initiated the > "video/H264" > subsession (client ports 58416-58417) > [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Set up the > "video/H264" su > bsession (client ports 58416-58417) > [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Created a data > sink for th > e "video/H264" subsession > [URL:"rtsp://192.168.33.132/onvif-media/media.amp/"]: Started playing > session... > > create new socket from accept() socket num: 532 > createNewClientConnection socket num: 532 > assignHandler socket num: 532 > create new socket from accept() socket num: 520 > createNewClientConnection socket num: 520 > assignHandler socket num: 520 > create socket from socket() num: 524 > closeSocket socket num: 524 > create socket from socket() num: 960 > closeSocket socket num: 960 > create socket from socket() num: 928 > create socket from socket() num: 924 > assignHandler socket num: 924 > assignHandler socket num: 520 > clearHandler socket num: 924 > assignHandler socket num: 924 > clearHandler socket num: 924 > closeSocket socket num: 928 > closeSocket socket num: 924 > clearHandler socket num: 520 > assignHandler socket num: 520 > clearHandler socket num: 520 > closeSocket fClientInputSocket num: 520 > create new socket from accept() socket num: 520 > createNewClientConnection socket num: 520 > assignHandler socket num: 520 > create socket from socket() num: 584 > create socket from socket() num: 588 > assignHandler socket num: 588 > assignHandler socket num: 520 > clearHandler socket num: 588 > assignHandler socket num: 588 > clearHandler socket num: 588 > closeSocket socket num: 584 > closeSocket socket num: 588 > clearHandler socket num: 520 > assignHandler socket num: 520 > clearHandler socket num: 520 > closeSocket fClientInputSocket num: 520 > create new socket from accept() socket num: 520 > createNewClientConnection socket num: 520 > assignHandler socket num: 520 > create socket from socket() num: 640 > create socket from socket() num: 1112 > assignHandler socket num: 1112 > assignHandler socket num: 520 > clearHandler socket num: 1112 > assignHandler socket num: 1112 > clearHandler socket num: 520 > clearHandler socket num: 520 > closeSocket fClientInputSocket num: 520 > create new socket from accept() socket num: 768 > createNewClientConnection socket num: 768 > assignHandler socket num: 768 > assignHandler socket num: 768 > clearHandler socket num: 1112 > assignHandler socket num: 1112 > assignHandler socket num: 520 > BasicTaskScheduler::SingleStep(): select() fails: No error > socket numbers used in the select() call: 288(r) 300(r) 520(re) > 532(re) 768(re) > 1112(r) > WinSock error 10038 > BasicTaskScheduler::SingleStep(): select() fails: No error > socket numbers used in the select() call: 288(r) 300(r) 520(re) > 532(re) 768(re) > 1112(r) > WinSock error 10038 > BasicTaskScheduler::SingleStep(): select() fails: No error > socket numbers used in the select() call: 288(r) 300(r) 520(re) > 532(re) 768(re) > 1112(r) > WinSock error 10038 > BasicTaskScheduler::SingleStep(): select() fails: No error > socket numbers used in the select() call: 288(r) 300(r) 520(re) > 532(re) 768(re) > 1112(r) > WinSock error 10038 > clearHandler socket num: 520 > clearHandler socket num: 768 > assignHandler socket num: 768 > clearHandler socket num: 768 > closeSocket fClientInputSocket num: 768 > create new socket from accept() socket num: 768 > createNewClientConnection socket num: 768 > assignHandler socket num: 768 > assignHandler socket num: 768 > clearHandler socket num: 1112 > assignHandler socket num: 1112 From finlayson at live555.com Thu Jun 27 01:14:08 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Jun 2013 01:14:08 -0700 Subject: [Live-devel] The option '-R' About openRTSP In-Reply-To: <54d57e25.2483.13f8347100e.Coremail.0574119@163.com> References: <54d57e25.2483.13f8347100e.Coremail.0574119@163.com> Message-ID: <7FABEBEA-2C21-4D11-AC6E-BBC4F3B92DEC@live555.com> > However, when we run this program ,the ?-R? option can not be used. Does running openRTSP -R not work for you? Then you may be using an old version of the software. Ensure that you are using the latest version of the software. See http://www.live555.com/liveMedia/faq.html#latest-version > So we want to have an idea of whether this option can be used, and you can provide some material concered. See also http://lists.live555.com/pipermail/live-devel/2013-June/017112.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From somesh.ballia at gmail.com Thu Jun 27 00:22:42 2013 From: somesh.ballia at gmail.com (Somesh Pathak) Date: Thu, 27 Jun 2013 12:52:42 +0530 Subject: [Live-devel] Adding Support of FLV container in LIVE555 (version 0.78) Message-ID: Hi, I am trying to add support for FLV streaming in Live555(Version 0.78), I have been taking MPEG1or2 as reference and have understood the basic architecture. The problem is inspite of doing all that I couldn?t get the steps which should be performed for successful addition of FLV container support in LIVE555. I am trying to extract elementary streams of audio and video from a FLV file and then stream it to a RTSP client (VLC 2.0.6) using LIVE555. I have written a parser which is extracting audio and video data form the file, but what I can't understand is 1) How to integrate the parser in the main code, and what classes (Source, sink, subsession etc) shall be created or modified. 2) Also do I need to add support of all the video and audio codecs supported in FLV container independently or just sending proper CODEC Id/Name in SDP does the job. 3) Any reference code/project available for FLV integration in Live555. Thanks Somesh Pathak -------------- next part -------------- An HTML attachment was scrubbed... URL: From zammargu at marvell.com Thu Jun 27 07:34:15 2013 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Thu, 27 Jun 2013 07:34:15 -0700 Subject: [Live-devel] Instrumentation to detect packet loss in my application In-Reply-To: <5F2D540A-1A16-4C9C-90D2-945D3EB6F9A4@live555.com> References: <5F2D540A-1A16-4C9C-90D2-945D3EB6F9A4@live555.com> Message-ID: Ross, Thanks for your prompt answer. Yes I read that link below about packet loss. That function increaseReceiveBufferTo is already called on server and client side of live555. Should it be replaced by a call from my application or should it be modified to fit my application? What I mean is do I need an additional call to this function in my application? Thanks. -Zahira From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, June 27, 2013 1:46 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Instrumentation to detect packet loss in my application The application I am running is loosing packets. This application runs a server and a client. On the server application an RTP server is running and on the client application an RTP client is running. I am trying to implement the live555 code to make sure that all packets that are sent from the RTP server are arriving to the RTP client. It looks from your documentation that live555 doesn't drop any packets That's correct. I assume you've read http://www.live555.com/liveMedia/faq.html#packet-loss In RTPInterface.cpp there is a function called sendPacket. I have added a printf there to detect the packet sent and its size. I would like to "recover" the same packet on the client side. Can you tell me what function does that on the client side? "RTPInterface::handleRead()" Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaobing at jriver.com Thu Jun 27 07:56:02 2013 From: yaobing at jriver.com (Yaobing Deng) Date: Thu, 27 Jun 2013 09:56:02 -0500 Subject: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime In-Reply-To: References: Message-ID: <51CC5282.4010805@jriver.com> On 6/27/2013 2:37 AM, live-devel-request at ns.live555.com wrote: > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Jun 2013 10:16:54 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > >> Thanks for the reminder about the GPL. I do have that in mind when I replied your last message (and sorry for forgetting to fix the subject line). Would it not be sufficient by making my changes public on this developer mailing list > No - because few (if any) of your customers subscribe to this mailing list. You could, however, put your modifications on your product's web site. > > For more about the LGPL and your obligations (and this applies to everyone who uses the "LIVE555 Streaming Media" software), see: > > http://www.live555.com/liveMedia/faq.html#copyright-and-license > > Once again, by far the simplest (and best solution) is just to get "SiliconBeach" to fix their hardware. (If anyone from "SiliconBeach" wants to get in touch with me, I'd be happy to work with them to help make their products standards-compliant.) > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ Thanks. An update: SiliconDust will soon release a firmware update that fixes this issue. Yaobing From zammargu at marvell.com Thu Jun 27 08:37:10 2013 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Thu, 27 Jun 2013 08:37:10 -0700 Subject: [Live-devel] Instrumentation to detect packet loss in my application In-Reply-To: <5F2D540A-1A16-4C9C-90D2-945D3EB6F9A4@live555.com> References: <5F2D540A-1A16-4C9C-90D2-945D3EB6F9A4@live555.com> Message-ID: I don't think this print is really what I want?? It looks like the packet argument in this function represents the datagram. What I want is have access to the packet being sent by the server and that same packet being read from the client. Can you help please? Thanks, -Zahira From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, June 27, 2013 1:46 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Instrumentation to detect packet loss in my application The application I am running is loosing packets. This application runs a server and a client. On the server application an RTP server is running and on the client application an RTP client is running. I am trying to implement the live555 code to make sure that all packets that are sent from the RTP server are arriving to the RTP client. It looks from your documentation that live555 doesn't drop any packets That's correct. I assume you've read http://www.live555.com/liveMedia/faq.html#packet-loss In RTPInterface.cpp there is a function called sendPacket. I have added a printf there to detect the packet sent and its size. I would like to "recover" the same packet on the client side. Can you tell me what function does that on the client side? "RTPInterface::handleRead()" Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 27 08:35:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Jun 2013 08:35:46 -0700 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <51CBE8C0.3040307@gosniias.ru> References: <51C00FF6.1080004@gosniias.ru> <51CBE8C0.3040307@gosniias.ru> Message-ID: <799A3869-3993-480D-9AAE-B51C0AED3F60@live555.com> Andrey, Thanks for looking into this. Your debugging output log seems to show what is going wrong: > closeSocket fClientInputSocket num: 520 > create new socket from accept() socket num: 768 > createNewClientConnection socket num: 768 > assignHandler socket num: 768 > assignHandler socket num: 768 > clearHandler socket num: 1112 > assignHandler socket num: 1112 > assignHandler socket num: 520 I.e., The code was attempting to handle socket 520 ("fClientInputSocket") after it had been closed. However, I still don't understand how this can be occurring. So please replace your "RTSPServer.cpp" and "RTPInterface.cpp" with the attached versions, that add some extra debugging output (but make no other changes). Then please send us the new debugging output, the next time you see the error. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTPInterface.cpp Type: application/octet-stream Size: 22539 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTSPServer.cpp Type: application/octet-stream Size: 90746 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 27 16:01:17 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Jun 2013 16:01:17 -0700 Subject: [Live-devel] Full HD Contents. trickplay question (with VLC) In-Reply-To: <2D2A3255ACBA744DA56BD7681C7DF2CA03610C4D@main.digicaps.co.kr> References: <2D2A3255ACBA744DA56BD7681C7DF2CA03610C4D@main.digicaps.co.kr> Message-ID: <65F0DD7E-EFAB-4A05-A8E0-23534BA58443@live555.com> > I had already conducted a test with VLC Media Player before testing with STB. (VLC v.2.0.6 and VLC v2.0.7) > > As you can see original file, 2x file is not animated as original file and 4x file is somehow animated but looks quite unnatural. > Could you please check it out again? Yes, I see the problem that you're referring to, but unfortunately I can't figure out specifically what's wrong with the videos. So I hope someone on this mailing list (with expertise in H.264/Transport Stream video) can help diagnose the problem. I have put the example files online at http://www.live555.com/ChunMyung/ Note the file "ChunMyung1.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1 - i.e., by running: testMPEG2TransportStreamTrickPlay ChunMyung.ts 0 1 ChunMyung1.ts Because our 'trick play' works by using I-frames only, this file effectively consists just of the i-frames from the original file. If you play this file in VLC, you can see that the I-frames freeze starting at about the 10 second mark, and do not resume until about the 1 minute mark. Does anyone know why? For another illustration of this, note the file "ChunMyung1-30.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1, but starting at the 30 second mark - i.e., by running: testMPEG2TransportStreamTrickPlay ChunMyung.ts 30 1 ChunMyung1-30.ts If you play this file in VLC, you can see that the video is 'empty' until about the 30 second mark (i.e., corresponding to about 1 minute into the original video). Does anyone know why? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Thu Jun 27 18:07:34 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Fri, 28 Jun 2013 01:07:34 +0000 Subject: [Live-devel] Full HD Contents. trickplay question (with VLC) In-Reply-To: <65F0DD7E-EFAB-4A05-A8E0-23534BA58443@live555.com> References: <2D2A3255ACBA744DA56BD7681C7DF2CA03610C4D@main.digicaps.co.kr> <65F0DD7E-EFAB-4A05-A8E0-23534BA58443@live555.com> Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D0110195D@postal.sonicfoundry.net> The file has a number of problems. Here a log output from a TS checker for file ChunMyung1.ts. Error Total count Description of last error PID of last error TS Packet with last error First Priority TS_sync_loss 0 - - - Sync_byte_error 0 - - - PAT_error_2 16 Sections with table_id 0x00 do not occur at least every 0,5 s on PID 0x0000 0x0 61325 PAT_error_2 [1] 16 Sections with table_id 0x00 do not occur at least every 0,5 s on PID 0x0000 0x0 61325 PAT_error_2 [2] 0 - - - PAT_error_2 [3] 0 - - - Continuity_count_error 0 - - - Continuity_count_error [1] 0 - - - Continuity_count_error [2] 0 - - - PMT_error_2 30 Sections with table_id 0x02, (i.e. a PMT), do not occur at least every 0,5 s on each program_map_PID which is referred to in the PAT 0x30 61325 PMT_error_2 [1] 30 Sections with table_id 0x02, (i.e. a PMT), do not occur at least every 0,5 s on each program_map_PID which is referred to in the PAT 0x30 61325 PMT_error_2 [2] 0 - - - PID_error 0 - Furthermore - I see an usually mapping between video slices and PES packets. For most files and the original (ChunMyung.ts) I see one video slice is mapped into one PES packet. The modified file ChunMyung1.ts contains 30+ PES packets per video slice which may not be illegal but definitely unusual and may trip a mpeg2 TS demuxer. Markus. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, June 27, 2013 6:01 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Full HD Contents. trickplay question (with VLC) I had already conducted a test with VLC Media Player before testing with STB. (VLC v.2.0.6 and VLC v2.0.7) As you can see original file, 2x file is not animated as original file and 4x file is somehow animated but looks quite unnatural. Could you please check it out again? Yes, I see the problem that you're referring to, but unfortunately I can't figure out specifically what's wrong with the videos. So I hope someone on this mailing list (with expertise in H.264/Transport Stream video) can help diagnose the problem. I have put the example files online at http://www.live555.com/ChunMyung/ Note the file "ChunMyung1.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1 - i.e., by running: testMPEG2TransportStreamTrickPlay ChunMyung.ts 0 1 ChunMyung1.ts Because our 'trick play' works by using I-frames only, this file effectively consists just of the i-frames from the original file. If you play this file in VLC, you can see that the I-frames freeze starting at about the 10 second mark, and do not resume until about the 1 minute mark. Does anyone know why? For another illustration of this, note the file "ChunMyung1-30.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1, but starting at the 30 second mark - i.e., by running: testMPEG2TransportStreamTrickPlay ChunMyung.ts 30 1 ChunMyung1-30.ts If you play this file in VLC, you can see that the video is 'empty' until about the 30 second mark (i.e., corresponding to about 1 minute into the original video). Does anyone know why? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From howtofly at gmail.com Thu Jun 27 19:16:11 2013 From: howtofly at gmail.com (Peng) Date: Fri, 28 Jun 2013 10:16:11 +0800 Subject: [Live-devel] Full HD Contents. trickplay question (with VLC) In-Reply-To: <51CCEED0.4050902@gmail.com> References: <51CCEED0.4050902@gmail.com> Message-ID: <51CCF1EB.7020902@gmail.com> sorry, forget editing the title. On 06/28/2013 09:07 AM, live-devel-request at ns.live555.com wrote: > > Note the file "ChunMyung1.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1 - i.e., by running: > testMPEG2TransportStreamTrickPlay ChunMyung.ts 0 1 ChunMyung1.ts > Because our 'trick play' works by using I-frames only, this file effectively consists just of the i-frames from the original file. If you play this file in VLC, you can see that the I-frames freeze starting at about the 10 second mark, and do not resume until about the 1 minute mark. Does anyone know why? > > For another illustration of this, note the file "ChunMyung1-30.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1, but starting at the 30 second mark - i.e., by running: > testMPEG2TransportStreamTrickPlay ChunMyung.ts 30 1 ChunMyung1-30.ts > If you play this file in VLC, you can see that the video is 'empty' until about the 30 second mark (i.e., corresponding to about 1 minute into the original video). Does anyone know why? Hi, Ross. I happened to be familiar with both TS and AVC. TS is a very special media container, whose playout axis is determined not only by PTS and the computer's system clock, but also by PCR encoded in the stream and the stream's bitrate, which determines the stream internal time axis. Very few TS muxers can operate in a complete standard way, one of them maybe Elecard. When VLC plays such improperly encoded files, inconsistency between the stream's internal axis and the computer's system clock may occur, which in turn leads to freezing pictures. A very simple way to check this, press ctrl+m when playing, set verbosity to 2, and save the log. There should be 'latter picture skipped' or 'too late to be displayed' warnings and 'more than 5 seconds' errors. Currently I use mobile connection to access internet. 90M is simply too large for me. When returning home, I volunteer to debug it. -- Peng From renatafaraco at gmail.com Fri Jun 28 12:38:52 2013 From: renatafaraco at gmail.com (Renata) Date: Fri, 28 Jun 2013 16:38:52 -0300 Subject: [Live-devel] Synchronization with Pelco Sarix Cameras In-Reply-To: <5F4038DA-BB21-4DDF-B05F-331841248FBE@live555.com> References: <5F4038DA-BB21-4DDF-B05F-331841248FBE@live555.com> Message-ID: Hello again, The MediaSink I am using is the QuickTimeFileSink from liveMedia. I am creating the FileSink this way: scs.qtOut = QuickTimeFileSink::createNew(env, *scs.session, fileName, 50000,480, 360,20,false,false,false,false); An example of a file I have recorded is posted here: http://fazion.com.br/biz/192.168.200.39-16-25-35.avi I tried with different fps and size of buffers, but with no success. Thanks for your attention again. Renata Faraco Cunha 2013/6/24 Ross Finlayson > I made a RTSP Client to receive a RTSP stream from a camera Pelco Sarix. > This stream has been saved in a MediaSink configured to have the same > parameters (frames per second, among others) of the stream. But, for each 1 > hour recorded I get a 1:03h video file.Is there anything I can do to get > and recording the stream at the same velocity? > > > Without knowing the details of what your "MediaSink" subclass looks like, > it's hard to answer this question. However, you should use the > 'presentation time' (that you get along with each received frame) to figure > out when each frame should be played. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 28 23:21:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Jun 2013 23:21:55 -0700 Subject: [Live-devel] Synchronization with Pelco Sarix Cameras In-Reply-To: References: <5F4038DA-BB21-4DDF-B05F-331841248FBE@live555.com> Message-ID: > The MediaSink I am using is the QuickTimeFileSink from liveMedia. > I am creating the FileSink this way: > > scs.qtOut = QuickTimeFileSink::createNew(env, *scs.session, fileName, > 50000,480, 360,20,false,false,false,false); > > An example of a file I have recorded is posted here: > http://fazion.com.br/biz/192.168.200.39-16-25-35.avi Good heavens! Why are you trying to write an AVI-format file using a "QuickTimeFileSink"? And why not just use the "openRTSP" application, which does all this for you: http://www.live555.com/openRTSP/ Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Sat Jun 29 02:39:44 2013 From: ashvyrkin at gosniias.ru (=?UTF-8?B?0JDQvdC00YDQtdC5?=) Date: Sat, 29 Jun 2013 13:39:44 +0400 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <799A3869-3993-480D-9AAE-B51C0AED3F60@live555.com> References: <51C00FF6.1080004@gosniias.ru> <51CBE8C0.3040307@gosniias.ru> <799A3869-3993-480D-9AAE-B51C0AED3F60@live555.com> Message-ID: <51CEAB60.5030707@gosniias.ru> Hi, Ross. Here's a new debug log output: RTSPClientConnection[060F24E0]::RTSPClientConnection() socket 568 SocketDescriptor[01377DD0]::SocketDescriptor() socket 568 SocketDescriptor[01377DD0]::registerRTPInterface(channel 0): socket 568 SocketDescriptor[01377DD0]::tcpReadHandler1(): socket 568: read error 1: -1 SocketDescriptor[01377DD0]::~SocketDescriptor() 1: socket 568, alt 5007D5A0, reo 1 RTSPClientConnection[060F24E0]::handleAlternativeRequestByte1() socket 568: 1 RTSPClientConnection[060F24E0]::~RTSPClientConnection() socket 568: 1 RTSPClientConnection[060F24E0]::~RTSPClientConnection() socket -1: 9 SocketDescriptor[01377DD0]::~SocketDescriptor() 9: socket 568, alt 5007D5A0, reo 1 RTSPClientConnection[060F24E0]::RTSPClientConnection() socket 1144 SocketDescriptor[01377DD0]::SocketDescriptor() socket 1144 SocketDescriptor[01377DD0]::registerRTPInterface(channel 0): socket 1144 SocketDescriptor[01377EE8]::SocketDescriptor() socket 568 SocketDescriptor[01377EE8]::registerRTPInterface(channel 1): socket 568 BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: And that's what will happen if the override function internalError() that it did not cause abort(): RTSPClientConnection[057E1788]::RTSPClientConnection() socket 524 SocketDescriptor[00858CB0]::SocketDescriptor() socket 524 SocketDescriptor[00858CB0]::registerRTPInterface(channel 0): socket 524 SocketDescriptor[00858CB0]::tcpReadHandler1(): socket 524: read error 1: -1 SocketDescriptor[00858CB0]::~SocketDescriptor() 1: socket 524, alt 5131D5A0, reo 1 RTSPClientConnection[057E1788]::handleAlternativeRequestByte1() socket 524: 1 RTSPClientConnection[057E1788]::~RTSPClientConnection() socket 524: 1 RTSPClientConnection[057E1788]::~RTSPClientConnection() socket -1: 9 SocketDescriptor[00858CB0]::~SocketDescriptor() 9: socket 524, alt 5131D5A0, reo 1 RTSPClientConnection[057E1788]::RTSPClientConnection() socket 1148 SocketDescriptor[008588A0]::SocketDescriptor() socket 1148 SocketDescriptor[008588A0]::registerRTPInterface(channel 0): socket 1148 SocketDescriptor[00858D28]::SocketDescriptor() socket 524 SocketDescriptor[00858D28]::registerRTPInterface(channel 1): socket 524 BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 292(r) 524(re) 872(r) 1148(re) BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 292(r) 524(re) 872(r) 1148(re) BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 292(r) 524(re) 872(r) 1148(re) SocketDescriptor[00858D28]::tcpReadHandler1(): socket 524: read error 1: -1 SocketDescriptor[00858D28]::~SocketDescriptor() 1: socket 524, alt 00000000, reo 1 SocketDescriptor[00858D28]::~SocketDescriptor() 9: socket 524, alt 00000000, reo 1 SocketDescriptor[008588A0]::tcpReadHandler1(): socket 1148: read error 1: -1 SocketDescriptor[008588A0]::~SocketDescriptor() 1: socket 1148, alt 5131D5A0, re o 1 RTSPClientConnection[057E1788]::handleAlternativeRequestByte1() socket 1148: 1 RTSPClientConnection[057E1788]::~RTSPClientConnection() socket 1148: 1 RTSPClientConnection[057E1788]::~RTSPClientConnection() socket -1: 9 SocketDescriptor[008588A0]::~SocketDescriptor() 9: socket 1148, alt 5131D5A0, re o 1 RTSPClientConnection[057E1788]::RTSPClientConnection() socket 1148 RTSPClientConnection[057E1788]::~RTSPClientConnection() socket 1148: 1 RTSPClientConnection[057E1788]::~RTSPClientConnection() socket -1: 9 RTSPClientConnection[057E1788]::RTSPClientConnection() socket 524 SocketDescriptor[00858AD0]::SocketDescriptor() socket 524 SocketDescriptor[00858CD8]::SocketDescriptor() socket 1148 SocketDescriptor[00858CD8]::registerRTPInterface(channel 1): socket 1148 SocketDescriptor[00858AD0]::registerRTPInterface(channel 1): socket 524 BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 292(r) 524(re) 872(r) 1148(re) BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 292(r) 524(re) 872(r) 1148(re) BasicTaskScheduler::SingleStep(): select() fails: No error socket numbers used in the select() call: 288(r) 292(r) 524(re) 872(r) 1148(re) SocketDescriptor[00858CD8]::tcpReadHandler1(): socket 1148: read error 1: -1 SocketDescriptor[00858CD8]::~SocketDescriptor() 1: socket 1148, alt 00000000, re o 1 SocketDescriptor[00858CD8]::~SocketDescriptor() 9: socket 1148, alt 00000000, re o 1 SocketDescriptor[00858AD0]::tcpReadHandler1(): socket 524: read error 1: -1 SocketDescriptor[00858AD0]::~SocketDescriptor() 1: socket 524, alt 5131D5A0, reo 1 RTSPClientConnection[057E1788]::handleAlternativeRequestByte1() socket 524: 1 RTSPClientConnection[057E1788]::~RTSPClientConnection() socket 524: 1 RTSPClientConnection[057E1788]::~RTSPClientConnection() socket -1: 9 SocketDescriptor[00858AD0]::~SocketDescriptor() 9: socket 524, alt 5131D5A0, reo 1 27.06.2013 19:35, Ross Finlayson ?????: > Andrey, > > Thanks for looking into this. > > Your debugging output log seems to show what is going wrong: > >> closeSocket fClientInputSocket num: 520 >> create new socket from accept() socket num: 768 >> createNewClientConnection socket num: 768 >> assignHandler socket num: 768 >> assignHandler socket num: 768 >> clearHandler socket num: 1112 >> assignHandler socket num: 1112 >> assignHandler socket num: 520 > > I.e., The code was attempting to handle socket 520 > ("fClientInputSocket") after it had been closed. However, I still > don't understand how this can be occurring. > > So please replace your "RTSPServer.cpp" and "RTPInterface.cpp" with > the attached versions, that add some extra debugging output (but make > no other changes). Then please send us the new debugging output, the > next time you see the error. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jun 29 15:20:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Jun 2013 15:20:46 -0700 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <51CEAB60.5030707@gosniias.ru> References: <51C00FF6.1080004@gosniias.ru> <51CBE8C0.3040307@gosniias.ru> <799A3869-3993-480D-9AAE-B51C0AED3F60@live555.com> <51CEAB60.5030707@gosniias.ru> Message-ID: <37937D71-19A5-467E-B5F4-69391C789CAC@live555.com> Andrey, Thanks again. I think (but am not yet 100% sure) that I've found and fixed the problem. Please replace your copy of "RTPInterface.cpp" with this one, and let me know (with debugging output) if you see the error again. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTPInterface.cpp Type: application/octet-stream Size: 24020 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Sat Jun 29 23:40:12 2013 From: ashvyrkin at gosniias.ru (Andrey) Date: Sun, 30 Jun 2013 10:40:12 +0400 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <37937D71-19A5-467E-B5F4-69391C789CAC@live555.com> References: <51C00FF6.1080004@gosniias.ru> <51CBE8C0.3040307@gosniias.ru> <799A3869-3993-480D-9AAE-B51C0AED3F60@live555.com> <51CEAB60.5030707@gosniias.ru> <37937D71-19A5-467E-B5F4-69391C789CAC@live555.com> Message-ID: <51CFD2CC.7010006@gosniias.ru> Thank you, Ross. Error no longer occurs. 30.06.2013 2:20, Ross Finlayson ?????: > Andrey, > > Thanks again. I think (but am not yet 100% sure) that I've found and > fixed the problem. Please replace your copy of "RTPInterface.cpp" > with this one, and let me know (with debugging output) if you see the > error again. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 30 00:55:21 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 30 Jun 2013 00:55:21 -0700 Subject: [Live-devel] windows winsock error 10038 In-Reply-To: <51CFD2CC.7010006@gosniias.ru> References: <51C00FF6.1080004@gosniias.ru> <51CBE8C0.3040307@gosniias.ru> <799A3869-3993-480D-9AAE-B51C0AED3F60@live555.com> <51CEAB60.5030707@gosniias.ru> <37937D71-19A5-467E-B5F4-69391C789CAC@live555.com> <51CFD2CC.7010006@gosniias.ru> Message-ID: <83521066-DF15-4F20-85E9-72692565DD54@live555.com> On Jun 29, 2013, at 11:40 PM, Andrey wrote: > Thank you, Ross. Error no longer occurs. That's great to hear. I've now installed a new version (2013.06.30) of the code that includes this fix. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From howtofly at gmail.com Sun Jun 30 00:43:15 2013 From: howtofly at gmail.com (Peng) Date: Sun, 30 Jun 2013 15:43:15 +0800 Subject: [Live-devel] Full HD Contents. trickplay question (with VLC) In-Reply-To: References: Message-ID: <51CFE193.5050509@gmail.com> >> Note the file "ChunMyung1.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1 - i.e., by running: >> testMPEG2TransportStreamTrickPlay ChunMyung.ts 0 1 ChunMyung1.ts >> Because our 'trick play' works by using I-frames only, this file effectively consists just of the i-frames from the original file. If you play this file in VLC, you can see that the I-frames freeze starting at about the 10 second mark, and do not resume until about the 1 minute mark. Does anyone know why? >> >> For another illustration of this, note the file "ChunMyung1-30.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1, but starting at the 30 second mark - i.e., by running: >> testMPEG2TransportStreamTrickPlay ChunMyung.ts 30 1 ChunMyung1-30.ts >> If you play this file in VLC, you can see that the video is 'empty' until about the 30 second mark (i.e., corresponding to about 1 minute into the original video). Does anyone know why? Hi, Ross. I just check ChunMyung.ts and ChunMyung1-30.ts. The empty 30 seconds has nothing to do with MPEG-TS container, it is caused by picture timing information carried within SPS and SEI of H.264 encoding. This point is that though testMPEG2TransportStreamTrickPlay picks I frames out, it does not modify the associated timing information accordingly. A feasible method to avoid this is to remove vui_parameters() (possibly together with hrd_parameters()) in SPS and to remove SEI completely. It seems that somebody has already done something very similar: http://forum.doom9.org/showthread.php?t=152419 Regards -- Peng From finlayson at live555.com Sun Jun 30 01:13:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 30 Jun 2013 01:13:06 -0700 Subject: [Live-devel] Handle carriage return/line feed in base64Decode In-Reply-To: <16E86A2D-58E8-43E7-A784-A6672DF8F502@live555.com> References: <017101ce6edd$9a006cf0$ce0146d0$@com> <16E86A2D-58E8-43E7-A784-A6672DF8F502@live555.com> Message-ID: On Jun 23, 2013, at 4:37 PM, Ross Finlayson wrote: >> I recently came across a client who sends our LIVE555 based RTSP server an HTTP message with a base64 encoded RTSP command that contains CR/LF. It seems fairly standard for a base64 decoder to support CR/LF, at least on 4 char boundaries, so I wrote up a patch to base64Decode to allow this. Then I discovered how the fragmented base64 message reading is implemented in RTSPServer and determined that the fix would not be so simple. > > Rather than put CR/LF (or other whitespace) removal inside the Base-64 decoding routine, we can just add a whitespace-removing pass to the "RTSPServer" code, before we call "base64Decode()". I'll add this change to the next release of the code. FYI, the latest version (2013.06.30) of the code includes this change. I hope it works OK for you. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: