From rwolf at digiop.com Mon Oct 1 08:36:45 2012 From: rwolf at digiop.com (Rex Wolf) Date: Mon, 1 Oct 2012 15:36:45 +0000 Subject: [Live-devel] RTP over TCP Message-ID: <28BE5601A97A154884BC2D71C1F6A8A301D0B562@INDMAIL.generalsolutions.net> I'm streaming RTP data over TCP from a network camera. Most of the time this works fine. But about once every 30 minutes (varies a lot) this particular camera sends some unexpected data between two RTP packets and that causes live555 to go into a state where it thinks it's receiving RTSP data and it never recovers from this. Below is a portion of the data captured from wireshark that causes the problem. The first chunk of data is the end of one RTP frame. After this is received, SocketDescriptor::tcpReadHandler1() goes into the AWAITING_DOLLAR state. As the next 112 bytes of data come in, it calls fServerRequestAlternativeByteHandler() to handle these bytes until it encounters the next $. The function fServerRequestAlternativeByteHandler() points to RTSPClient::handleAlternativeRequestByte() which simply calls RTSPClient::handleAlternativeRequestByte1(). Now RTSPClient::handleAlternativeRequestByte1() normally just calls RTSPClient::handleResponseBytes() to handle this data, thinking that it should be an RTSP response. But this is unknown binary data and the 28th bytes of it happens to be a 0xfe, which RTSPClient::handleAlternativeRequestByte1() treats as a special character that means the current data handler no longer needs any data so install RTSPClient::incomingDataHandler as the new data handler. All incoming data now goes to RTSPClient::incomingDataHandler(), but since the data coming in is still RTP data, RTSPClient::fResponseBuffer just keeps overflowing forever with RTP data. To prevent this situation, I tried adding a check to SocketDescriptor::tcpReadHandler1() in the AWAITING_DOLLAR case to prevent it from calling fServerRequestAlternativeByteHandler if the byte read was 0xFF or 0xFE. This is, of course, a hack on top of a hack. But it does keep SocketDescriptor::tcpReadHandler1() as the incoming data handler and allows it to pick back up at the start of the next RTP packet. I've contacted the camera vendor to find out why they put this mystery data in between the RTP packets sometimes. But here I wanted to ask if that was even allowed per the RTSP spec and if my proposed change was acceptable or if there's a better way to handle this situation. 0310 50 8b 8f 84 2a a3 62 1e d3 6a 40 91 8b f4 31 51 P...*.b..j at ...1Q 0320 29 bd ce a1 05 02 3d 49 fe 1e 87 fd 2a 27 cc 78 ).....=I....*'.x 0330 1d 40 f0 c5 19 60 c5 37 b9 69 30 73 fd a6 d3 fa . at ...`.7.i0s.... <== end of previous frame 0340 82 04 3a dd cd 10 35 e7 67 1a b4 95 83 08 e6 a7 ..:...5.g....... <== start of 112 bytes of mystery data 0350 02 6a 81 f9 87 72 3c 3e 7f ee bf fe cc 73 dd 54 .j...r<>.....s.T <== 0xfe appears in the stream 0360 9d 1b 67 10 5a 21 b6 8a 06 9b 84 b1 08 98 15 cc ..g.Z!.......... 0370 89 42 f8 90 80 72 5e 67 8e a0 86 43 cd f6 a6 cf .B...r^g...C.... 0380 b5 41 55 d1 a1 9e 75 e8 c2 18 77 06 d8 d1 be 9a .AU...u...w..... 0390 79 a7 3a 97 24 7a 2f fd b3 fb c5 6e d8 ee 86 8d y.:.$z/....n.... 03a0 bb 56 cc f7 1f 4c 8d 52 5f f9 2d 02 19 af 05 31 .V...L.R_.-....1 03b0 24 00 20 0c 80 60 0f 0e db 0f ee cc 9b 05 ae d1 $. ..`.......... <== start of next frame ('$', channel 0, 0x200c bytes) 03c0 7c 05 1c 09 de 8e 50 88 af 46 15 1b 10 74 7b 97 |.....P..F...t{. 03d0 6c 4b b0 00 05 5a 4c 1a 81 86 a9 e5 ed fe cc 12 lK...ZL......... Thanks for your help, Rex Wolf -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 1 09:24:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Oct 2012 09:24:15 -0700 Subject: [Live-devel] RTP over TCP In-Reply-To: <28BE5601A97A154884BC2D71C1F6A8A301D0B562@INDMAIL.generalsolutions.net> References: <28BE5601A97A154884BC2D71C1F6A8A301D0B562@INDMAIL.generalsolutions.net> Message-ID: <15161520-DB61-48A0-8A88-9D7AC811309A@live555.com> > To prevent this situation, I tried adding a check to SocketDescriptor::tcpReadHandler1() in the AWAITING_DOLLAR case to prevent it from calling fServerRequestAlternativeByteHandler if the byte read was 0xFF or 0xFE. This is, of course, a hack on top of a hack. Yes, but since the original 'hack' (i.e., using 0xFE and 0xFF as special 'signaling' bytes) relies upon the fact that we don't expect these characters to appear within RTSP requests or responses, it seems reasonable to modify the code - as you did - to check for this. Just to make sure we're on the same page here, please send a "diff" containing your modification, and I'll include it in the next release of the software. > I?ve contacted the camera vendor to find out why they put this mystery data in between the RTP packets sometimes. But here I wanted to ask if that was even allowed per the RTSP spec No, definitely not. There shouldn't be any extra data like this appearing in the TCP stream. It's apparently a bug in the network camera. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Mon Oct 1 10:06:37 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Mon, 01 Oct 2012 10:06:37 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: <8ED913A9-BA64-4D3A-9795-E7387E08E0DD@live555.com> References: <5060D798.8080903@schuckmannacres.com> <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> <50623290.9000703@schuckmannacres.com> <7ACA8583-BA4A-48F8-A865-7AA6B480CF79@live555.com> <50637D35.8040001@schuckmannacres.com> <50647F95.2000209@schuckmannacres.com> <8ED913A9-BA64-4D3A-9795-E7387E08E0DD@live555.com> Message-ID: <5069CD9D.7060403@schuckmannacres.com> Ok cool thanks. Matt S. On Friday, September 28, 2012 2:04:43 PM, Ross Finlayson wrote: >>> I'm not quite sure how it works if fReuseFirstSource is set and one >>> client requests a TCP connection and another a UDP? >> >> Aha! There's actually a bug in the current code that prevents this >> from working properly. > > It turns out that I was mistaken about this. The current code handles > this situation correctly, I think. (If "fReuseFirstSource" is set, > then each client's connection will use the same "StreamState" object, > but with different "Destinations" objects. Everything should work OK...) > > 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 From rwolf at digiop.com Mon Oct 1 10:52:55 2012 From: rwolf at digiop.com (Rex Wolf) Date: Mon, 1 Oct 2012 17:52:55 +0000 Subject: [Live-devel] RTP over TCP In-Reply-To: <15161520-DB61-48A0-8A88-9D7AC811309A@live555.com> References: <28BE5601A97A154884BC2D71C1F6A8A301D0B562@INDMAIL.generalsolutions.net> <15161520-DB61-48A0-8A88-9D7AC811309A@live555.com> Message-ID: <28BE5601A97A154884BC2D71C1F6A8A301D0B682@INDMAIL.generalsolutions.net> Ross, Thanks for the quick reply. Here is the diff of the changes I propose to the AWAITING_DOLLAR case in SocketDescriptor::tcpReadHandler1(). Rex case AWAITING_DOLLAR: { if (c == '$') { #ifdef DEBUG_RECEIVE fprintf(stderr, "SocketDescriptor(socket %d)::tcpReadHandler(): Saw '$'\n", fOurSocketNum); #endif fTCPReadingState = AWAITING_STREAM_CHANNEL_ID; } else { // This character is part of a RTSP request or command, which is handled separately: if (fServerRequestAlternativeByteHandler != NULL) { (*fServerRequestAlternativeByteHandler)(fServerRequestAlternativeByteHandlerClientData, c); } } break; } ------------------------------------------------------------------------------------------------------- case AWAITING_DOLLAR: { if (c == '$') { #ifdef DEBUG_RECEIVE fprintf(stderr, "SocketDescriptor(socket %d)::tcpReadHandler(): Saw '$'\n", fOurSocketNum); #endif fTCPReadingState = AWAITING_STREAM_CHANNEL_ID; } else { // This character is part of a RTSP request or command, which is handled separately: if ((fServerRequestAlternativeByteHandler != NULL) && (c != 0xFF) && (c != 0xFE)) { // FF and FE are treated as special chars, so don't send them (*fServerRequestAlternativeByteHandler)(fServerRequestAlternativeByteHandlerClientData, c); } } break; } From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, October 01, 2012 12:24 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP over TCP To prevent this situation, I tried adding a check to SocketDescriptor::tcpReadHandler1() in the AWAITING_DOLLAR case to prevent it from calling fServerRequestAlternativeByteHandler if the byte read was 0xFF or 0xFE. This is, of course, a hack on top of a hack. Yes, but since the original 'hack' (i.e., using 0xFE and 0xFF as special 'signaling' bytes) relies upon the fact that we don't expect these characters to appear within RTSP requests or responses, it seems reasonable to modify the code - as you did - to check for this. Just to make sure we're on the same page here, please send a "diff" containing your modification, and I'll include it in the next release of the software. I've contacted the camera vendor to find out why they put this mystery data in between the RTP packets sometimes. But here I wanted to ask if that was even allowed per the RTSP spec No, definitely not. There shouldn't be any extra data like this appearing in the TCP stream. It's apparently a bug in the network camera. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic.nadeau at transport.alstom.com Mon Oct 1 11:36:14 2012 From: frederic.nadeau at transport.alstom.com (NADEAU Frederic -EXT) Date: Mon, 1 Oct 2012 18:36:14 +0000 Subject: [Live-devel] SIP Stack issue on BYE Message-ID: <887184C35EAC384EA0867D9A0D3C6B66AD095E@041-DB3MPN1-102.041d.mgd.msft.net> Hi, We found an issue in SIPClient.cpp in function sendBye() http://www.live555.com/liveMedia/doxygen/html/SIPClient_8cpp-source.html line 682 reads: "CSeq: %d ACK\r\n" It should be changed for "CSeq: %d BYE\r\n" Our setup is as follow: FreeSWITCH Version 1.2.0-rc2+git~20120730T235848Z~3b5b59e693 Default install, except that we disabled register. playSIP works fine, except that when we kill the session,(playSIP sends BYE), both Wireshark and FreeSWITCH log shows that FreeSWITCH return a BAD REQUEST to the BYE REQUEST. This would comply with RFC 3261. RFC 3665 has numerous examples. See http://tools.ietf.org/html/rfc3665 page 22 for a quick example. Thanks for Live555, Fr?d?ric Nadeau ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. From finlayson at live555.com Mon Oct 1 13:08:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Oct 2012 13:08:15 -0700 Subject: [Live-devel] SIP Stack issue on BYE In-Reply-To: <887184C35EAC384EA0867D9A0D3C6B66AD095E@041-DB3MPN1-102.041d.mgd.msft.net> References: <887184C35EAC384EA0867D9A0D3C6B66AD095E@041-DB3MPN1-102.041d.mgd.msft.net> Message-ID: Thanks. I have just released a new version (2012.10.01) of the code that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xingskycn at 163.com Mon Oct 1 05:39:09 2012 From: xingskycn at 163.com (Leon) Date: Mon, 1 Oct 2012 20:39:09 +0800 Subject: [Live-devel] Cannot to get the stream data on RTSP-TCP mode. Message-ID: <35CC6F36-54EE-4045-9971-14119F48DBCA@163.com> Dear , I Cannot recv the stream data on RTSP-TCP mode, The system returns the following information. However , in the RTSP-UDP mode is normal, Please Help Me! Attachment is DEBUG message . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: debug.txt URL: -------------- next part -------------- schedule(0.437185->1349090861.150699) Received 6355 new bytes of response data. Received 3326 new bytes of response data. Received 3409 new bytes of response data. Received 3048 new bytes of response data. Received 2639 new bytes of response data. Received 579 new bytes of response data. Received 2529 new bytes of response data. Received 1188 new bytes of response data. Received 1867 new bytes of response data. Received 3160 new bytes of response data. Received 2903 new bytes of response data. Received 2904 new bytes of response data. Received 1452 new bytes of response data. Received 1188 new bytes of response data. Received 98 new bytes of response data. Received 2089 new bytes of response data. Received 1451 new bytes of response data. Received 2407 new bytes of response data. sending REPORT sending RTCP packet 80c90001 d9c3c4b9 81ca0005 d9c3c4b9 010b4c65 6f6e2d69 50686f6e 65000000 schedule(4.866605->1349090866.020221) Received 3112 new bytes of response data. Received 2777 new bytes of response data. Received 2982 new bytes of response data. Received 3080 new bytes of response data. Received 1537 new bytes of response data. Received 1188 new bytes of response data. Received 263 new bytes of response data. Received 1188 new bytes of response data. Received 653 new bytes of response data. Received 4091 new bytes of response data. Received 3385 new bytes of response data. From finlayson at live555.com Mon Oct 1 15:55:44 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Oct 2012 15:55:44 -0700 Subject: [Live-devel] Cannot to get the stream data on RTSP-TCP mode. In-Reply-To: <35CC6F36-54EE-4045-9971-14119F48DBCA@163.com> References: <35CC6F36-54EE-4045-9971-14119F48DBCA@163.com> Message-ID: Your log shows that your server is using an out-of-date version of the "LIVE555 Streaming Media" code. You should first use an up-to-date version of the "LIVE555 Media Server" as your server, and an up-to-date version of "openRTSP" (using the "-t" option, to request RTP-over-TCP streaming) as your client. Once you have verified that streaming works OK with this configuration, only then should you try developing your own code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Wed Oct 3 04:32:24 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Wed, 03 Oct 2012 13:32:24 +0200 Subject: [Live-devel] Android Usage Environment Message-ID: <506C3E680200004D000749B7@pta-emo.csir.co.za> Hi Ross,I'm not sure whether you want platform specific code to be part of the live555 code base, but since there does seem to be increased activity/interest with regards to running live555 on Android, perhaps the attached AndroidUsageEnvironment class may be of use. It's a copy of the BasicUsageEnvironment class modified for Android-specific logging. The entire class is inside a "#ifdef ANDROID" directive so it shouldn't interfere with other code. Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: AndroidUsageEnvironment.hh Type: application/octet-stream Size: 1778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AndroidUsageEnvironment.cpp Type: application/octet-stream Size: 2260 bytes Desc: not available URL: From rglobisch at csir.co.za Wed Oct 3 04:23:06 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Wed, 03 Oct 2012 13:23:06 +0200 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> Message-ID: <506C3C3A0200004D000749A1@pta-emo.csir.co.za> Hi Ross, Thanks for the quick fix! Preliminary tests confirm that the early RR is not being sent anymore. Upon testing the fix we ran into another seemingly related issue. We now have the situation where the fix is allowing another issue to appear, that I have definitely also seen in the past, but at the time didn't know what to make of it. We suspect that the problem is now reversed: after the client sends the PLAY request, it receives RTP/RTCP data over the TCP connection before it receives the 200 OK and then fails with the "RTSP response was truncated. Increase "RTSPClient::responseBufferSize" message. To recap, we are streaming from a live555 server to VLC running on an Android-based mobile device and the delays in the connection allow this issue to appear. The issue has *seldomly* occurred when streaming to desktops over "better" Internet connections. Attached are the server side and client device wireshark traces. Since it wasn't immediately apparent from the client trace that the client is receiving RTP data, I added some debug logging to output the buffer contents in RTSPClient.cpp. An excerpt of the log follows: 10-03 12:44:03.453: D/live555(871): RTSP/1.0 200 OK 10-03 12:44:03.453: D/live555(871): CSeq: 5 10-03 12:44:03.453: D/live555(871): Date: Wed, Oct 03 2012 10:42:28 GMT 10-03 12:44:03.453: D/live555(871): Transport: RTP/AVP/TCP;unicast;destination=88.75.220.178;source=192.168.122.130;interleaved=2-3 10-03 12:44:03.453: D/live555(871): Session: 51717F51 10-03 12:44:03.453: D/live555(871): 10-03 12:44:03.453: D/VLC(871): [0x41bf48]: live555 demux setup start: 0.000000 stop:0.000000 10-03 12:44:03.833: D/live555(871): ? 10-03 12:44:03.833: D/live555(871): ?? 10-03 12:44:03.833: D/live555(871): ??? 10-03 12:44:03.833: D/live555(871): ???* 10-03 12:44:03.833: D/live555(871): ???*? 10-03 12:44:03.833: D/live555(871): ???*?? 10-03 12:44:03.833: D/live555(871): ???*??g 10-03 12:44:03.833: D/live555(871): ???*??g? ... ... 10-03 12:44:03.838: D/live555(871): ???*??g?"O? 10-03 12:44:03.838: D/live555(871): Received 10-03 12:44:03.838: D/live555(871): 1378 10-03 12:44:03.838: D/live555(871): new bytes of response data: 10-03 12:44:03.838: D/live555(871): ???*??g?"O? 10-03 12:44:03.893: D/live555(871): Received 10-03 12:44:03.893: D/live555(871): 1440 10-03 12:44:03.893: D/live555(871): new bytes of response data: 10-03 12:44:03.893: D/live555(871): ???*??g?"O? 10-03 12:44:03.918: D/live555(871): Received 10-03 12:44:03.918: D/live555(871): 1440 10-03 12:44:03.918: D/live555(871): new bytes of response data: 10-03 12:44:03.918: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:03.918: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:03.958: D/live555(871): Received 10-03 12:44:03.958: D/live555(871): 1440 10-03 12:44:03.958: D/live555(871): new bytes of response data: 10-03 12:44:03.958: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:03.958: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:04.073: D/live555(871): Received 10-03 12:44:04.073: D/live555(871): 1412 10-03 12:44:04.073: D/live555(871): new bytes of response data: 10-03 12:44:04.078: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:04.078: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:04.303: D/live555(871): Received 10-03 12:44:04.303: D/live555(871): 1650 10-03 12:44:04.308: D/live555(871): new bytes of response data: 10-03 12:44:04.308: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:04.308: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:04.623: D/live555(871): Received 10-03 12:44:04.623: D/live555(871): 1097 10-03 12:44:04.623: D/live555(871): new bytes of response data: 10-03 12:44:04.623: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:04.623: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:04.783: D/live555(871): Received 10-03 12:44:04.783: D/live555(871): 1440 10-03 12:44:04.783: D/live555(871): new bytes of response data: 10-03 12:44:04.783: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:04.783: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:04.848: D/live555(871): Received 10-03 12:44:04.848: D/live555(871): 358 10-03 12:44:04.853: D/live555(871): new bytes of response data: 10-03 12:44:04.853: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:04.853: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:05.133: D/live555(871): Received 10-03 12:44:05.143: D/live555(871): 1302 10-03 12:44:05.143: D/live555(871): new bytes of response data: 10-03 12:44:05.143: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:05.143: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:05.333: D/live555(871): Received 10-03 12:44:05.333: D/live555(871): 1440 10-03 12:44:05.338: D/live555(871): new bytes of response data: 10-03 12:44:05.338: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:05.338: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:05.363: D/live555(871): Received 10-03 12:44:05.363: D/live555(871): 221 10-03 12:44:05.363: D/live555(871): new bytes of response data: 10-03 12:44:05.363: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:05.363: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:05.703: D/live555(871): Received 10-03 12:44:05.703: D/live555(871): 1328 10-03 12:44:05.703: D/live555(871): new bytes of response data: 10-03 12:44:05.703: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:05.703: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:05.888: D/live555(871): Received 10-03 12:44:05.888: D/live555(871): 1440 10-03 12:44:05.888: D/live555(871): new bytes of response data: 10-03 12:44:05.888: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:05.888: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:05.928: D/live555(871): Received 10-03 12:44:05.928: D/live555(871): 331 10-03 12:44:05.928: D/live555(871): new bytes of response data: 10-03 12:44:05.928: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:05.928: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:06.258: D/live555(871): Received 10-03 12:44:06.258: D/live555(871): 1394 10-03 12:44:06.263: D/live555(871): new bytes of response data: 10-03 12:44:06.263: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:06.263: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:06.428: D/live555(871): Received 10-03 12:44:06.428: D/live555(871): 1440 10-03 12:44:06.433: D/live555(871): new bytes of response data: 10-03 12:44:06.433: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:06.433: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:06.488: D/live555(871): Received 10-03 12:44:06.488: D/live555(871): 403 10-03 12:44:06.488: D/live555(871): new bytes of response data: 10-03 12:44:06.488: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:06.488: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:06.773: D/live555(871): Received 10-03 12:44:06.773: D/live555(871): 1344 10-03 12:44:06.773: D/live555(871): new bytes of response data: 10-03 12:44:06.773: D/live555(871): p??{???+?w????*???S*????S?9?,r?s????9?%?Z5???9U?G?x??x?????? 10-03 12:44:06.773: D/live555(871): n*???44?Y8~X,87?i?b?Fw> ?? ?7??eP?|?wG`dd?S??*?p?C!?!???L??[?,??+??$ 10-03 12:44:07.083: E/VLC(871): [0x41bf48]: live555 demux RTSP PLAY failed RTSP response was truncated. Increase "RTSPClient::responseBufferSize" The full debug log is also attached in case that helps. I'm guessing that this is the RTP RTCP data and the '$' signs seem to confirm that. What are your thoughts on this and any idea how hard it would be to fix? Best regards, Ralf >>> Ross Finlayson 11/09/12 6:47 AM >>> FYI, I've now installed a new version (2012.09.11) of the "LIVE555 Streaming Media" code that fixes the problem with clients occasionally sending RTCP "RR" packets 'early' (when streaming RTP/RTCP-over-TCP). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: client.log Type: application/octet-stream Size: 7846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: server.log Type: application/octet-stream Size: 52966 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vlc_live555_log.txt URL: From finlayson at live555.com Thu Oct 4 08:47:53 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Oct 2012 08:47:53 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <506C3C3A0200004D000749A1@pta-emo.csir.co.za> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <506C3C3A0200004D000749A1@pta-emo.csir.co.za> Message-ID: <737D7C5A-DC55-455E-ABAE-91126611BF38@live555.com> > We suspect that the problem is now reversed: after the client sends the > PLAY request, > it receives RTP/RTCP data over the TCP connection before it receives the > 200 OK Ralf, Thanks for the report. I've just installed a new version (2012.10.04) of the code that should fix this. When a "RTSPClient" requests RTP/RTCP-over-TCP streaming, it is (once again) prepared to handle incoming RTP/RTCP-over-TCP data as soon as it receives the "SETUP" response, but doesn't start sending RTCP "RR" packets until after it receives the "PLAY" response. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruno.Marchand at averna.com Thu Oct 4 09:23:03 2012 From: Bruno.Marchand at averna.com (Bruno Marchand) Date: Thu, 4 Oct 2012 12:23:03 -0400 Subject: [Live-devel] Suggestions Message-ID: Hi, I have two suggestions of modification to the code. Well, it is at least things I've added to the library I'm using. The first modification is to avoid compilation warnings under windows. It is just to add the file "errno.h" in "Netcommon.h". This way the redefinition warnings do not appear and disappear depending on inclusion order. #if defined(__WIN32__) || defined(_WIN32) || defined(_WIN32_WCE) /* Windows */ #if defined(WINNT) || defined(_WINNT) || defined(__BORLANDC__) || defined(__MINGW32__) || defined(_WIN32_WCE) || defined (_MSC_VER) #define _MSWSOCK_ #include #include #endif #include + #include #include The second suggestion is about the stream replicator. I observed that component do not pass doStopGettingFrame to its source. I don't know if it is on purpose though. In my application, the source needs to know when all replicas stop so I added this to the end of the function "deactivateStreamReplica": if(fNumActiveReplicas == 0) { fInputSource->stopGettingFrames(); //last replica stop, pass message to source } I hope these suggestions can be of some use. Regards, Bruno Marchand -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 4 16:12:00 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Oct 2012 16:12:00 -0700 Subject: [Live-devel] Android Usage Environment In-Reply-To: <506C3E680200004D000749B7@pta-emo.csir.co.za> References: <506C3E680200004D000749B7@pta-emo.csir.co.za> Message-ID: > I'm not sure whether you want platform specific code to be part of the live555 code base Yes, perhaps - although the place to put such code would be a separate directory (with its own library) - as we currently do for "WindowsAudioInputDevice". (So, if this were done, there'd be no need for "#ifdef ANDROID" directives.) > but since there does seem to be increased activity/interest with regards to running live555 on Android, > perhaps the attached AndroidUsageEnvironment class may be of use. > It's a copy of the BasicUsageEnvironment class modified for Android-specific logging. Does "stderr" (as used by the default "BasicUsageEnvironment" implementation) not go somewhere sensible on Android? Anyway, I might end up adding this sometime in the future, but it's not a high priority. (In the meantime, if people want this, they can get these files from the mailing list archive.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 4 22:55:49 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Oct 2012 22:55:49 -0700 Subject: [Live-devel] Suggestions In-Reply-To: References: Message-ID: <7F58C1C7-5BC0-40D2-B425-1DE5D0943454@live555.com> Thanks. These two changes 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 Bruno.Marchand at averna.com Fri Oct 5 04:41:45 2012 From: Bruno.Marchand at averna.com (Bruno Marchand) Date: Fri, 5 Oct 2012 07:41:45 -0400 Subject: [Live-devel] Suggestions In-Reply-To: <7F58C1C7-5BC0-40D2-B425-1DE5D0943454@live555.com> References: <7F58C1C7-5BC0-40D2-B425-1DE5D0943454@live555.com> Message-ID: Hi Ross, A little mistake on my side, the condition for the StreamReplicator should be if(fNumActiveReplicas == 0 && fInputSource != NULL) I forgot to the pointer because it is never NULL in my application but it could be on others. Sorry. Regards, Bruno From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 5 octobre 2012 01:56 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Suggestions Thanks. These two changes 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 rglobisch at csir.co.za Fri Oct 5 10:29:42 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Fri, 05 Oct 2012 19:29:42 +0200 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <737D7C5A-DC55-455E-ABAE-91126611BF38@live555.com> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <506C3C3A0200004D000749A1@pta-emo.csir.co.za> <737D7C5A-DC55-455E-ABAE-91126611BF38@live555.com> Message-ID: <506F35260200004D00074D52@pta-emo.csir.co.za> > I've just installed a new version (2012.10.04) of the code that should fix this. When a "RTSPClient" requests RTP/RTCP-over-TCP streaming, it is (once again) prepared to handle incoming RTP/RTCP-over-TCP data as soon as it receives the "SETUP" response, but doesn't start sending RTCP "RR" packets until after it receives the "PLAY" response. Thanks Ross, that was fast! I will report back as soon as we have upgraded the system and tested it. Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From rglobisch at csir.co.za Sun Oct 7 03:24:26 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Sun, 07 Oct 2012 12:24:26 +0200 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <737D7C5A-DC55-455E-ABAE-91126611BF38@live555.com> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <506C3C3A0200004D000749A1@pta-emo.csir.co.za> <737D7C5A-DC55-455E-ABAE-91126611BF38@live555.com> Message-ID: <5071747A0200004D00074DD1@pta-emo.csir.co.za> Hi Ross, > When a "RTSPClient" requests RTP/RTCP-over-TCP streaming, it is (once again) prepared to handle incoming RTP/RTCP-over-TCP data as soon as it receives the "SETUP" response, but doesn't start sending RTCP "RR" packets until after it receives the "PLAY" response. Just wanted to double check: it sounds like a server side upgrade is not necessary for the fix? I just tested the new release without upgrading the server and I still get the "response buffer truncated" error message in VLC, although it looks slightly different in that it seems to parse the RTSP 200 OK once the response has been successfully received (around line 2237). An excerpt of the log is attached, I've tried to trim it down to the most important parts, but it's still lengthy. Also, I'm not sure if it tells you anything, but every other time log cat starts spewing out the "RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase"maxRTCPPacketSize" message in RTCPInstance::incomingReportHandler1, which seems to indicate that somehow the RTCP handler is parsing RTP messages? Please let me know if you want me to add any logging lines to the live555 code, if that should be of any help in tracking down the issue. Cheers, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vlc_log_excerpt.txt URL: From finlayson at live555.com Sun Oct 7 07:00:17 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 7 Oct 2012 07:00:17 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <5071747A0200004D00074DD1@pta-emo.csir.co.za> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <506C3C3A0200004D000749A1@pta-emo.csir.co.za> <737D7C5A-DC55-455E-ABAE-91126611BF38@live555.com> <5071747A0200004D00074DD1@pta-emo.csir.co.za> Message-ID: > Just wanted to double check: it sounds like a server side upgrade is not necessary for the fix? It shouldn't have been. However, I see from your log that your server code is almost 1 year out of date, so I suggest upgrading it anyway. > I just tested the new release without upgrading the server and I still get the "response buffer truncated" error message in VLC, although it looks slightly different in that it seems to parse the RTSP 200 OK once the response has been successfully received (around line 2237). The actual problem is starting at line 692 of your log. The RTSP client's 'alternative byte handler' (which gets called by the TCP read handling code whenever it thinks that the received data should be part of a RTSP response (rather than an embedded RTP or RTCP packet)) is receiving weird binary (i.e., non-ASCII) data. Apparently this weird binary data does not begin with a '$' (i.e., 0x24) character, otherwise our TCP read handling code would have recognized it as beginning an embedded RTP or RTCP packet. Does this problem happen *always* whenever you stream from this particular server (in RTP/RTCP-over-TCP mode), or only *sometimes* from this server (e.g., only when the network is congested)? > Please let me know if you want me to add any logging lines to the live555 code, if that should be of any help in tracking down the issue. If the problem still happens - even after you've upgraded your server - then please add the line #define DEBUG_RECEIVE 1 to the start of "liveMedia/RTPInterface.cpp" (for your client), recompile your client, and send us another log (when you see the error happening again). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix at embedded-sol.com Sun Oct 7 11:12:25 2012 From: felix at embedded-sol.com (Felix Radensky) Date: Sun, 07 Oct 2012 20:12:25 +0200 Subject: [Live-devel] Streaming in wireless ad-hoc network Message-ID: <5071C609.5000300@embedded-sol.com> An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Oct 7 12:52:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 7 Oct 2012 12:52:51 -0700 Subject: [Live-devel] Streaming in wireless ad-hoc network In-Reply-To: <5071C609.5000300@embedded-sol.com> References: <5071C609.5000300@embedded-sol.com> Message-ID: <9E80716B-78E2-48E5-8F0A-9996D8315F66@live555.com> > I'm having a real trouble getting live555 based streamer work in wireless > ad-hoc network. The same streamer works fine in wired and managed > wireless networks. [...] > Any idea what can be wrong with my application would be greatly appreciated. If the only difference between your application working and your application not working is the network on which your computers run, then the problem seems unlikely to be your application. The problem is probably the network. Multicast over WiFi networks frequently performs poorly - supporting fairly low bit rates only (unless the WiFi network has been especially configured to support higher bit rates). That is likely to be especially true of ad-hoc WIFi networks. However... > Streaming from file using testH264VideoStreamer works fine. That's strange. Does your file have the same bit rate as your live stream - i.e., was your file recorded simply by dumping the output of your decoder (rather than, for example, taking one of the example ".h264" files from our web site)? If so, then I can't explain what you're seeing. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb at tmxvoip.com Sun Oct 7 11:49:09 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Sun, 7 Oct 2012 21:49:09 +0300 Subject: [Live-devel] Streaming in wireless ad-hoc network References: <5071C609.5000300@embedded-sol.com> Message-ID: hello what is your embedded distro ? please try to create a bridge and atach your wlan interface to it so the ip address will be in the bridge if you have a 2.6 kernel, IGMP snooping will automaticaly be inabled in your bridge this may 90% solv your multicast over wireless issue i am streaming 20channels over wireless but encoded in H.264/AAC using MumuDVB without any issue at all 802.11N is recomanded but 99.99% will not work in ad-hoc mode thank you ----- Original Message ----- From: "Felix Radensky" To: "LIVE555 Streaming Media - development & use" Sent: Sunday, October 07, 2012 9:12 PM Subject: [Live-devel] Streaming in wireless ad-hoc network > Hi, > > I'm having a real trouble getting live555 based streamer work in wireless > ad-hoc network. The same streamer works fine in wired and managed > wireless networks. > > My setup consists of embedded device and Linux based laptop. > The live555 application runs on embedded device and streams > live H.264 video over multicast. Video resolution is 640x480, frame > rate is 30 FPS. VLC on laptop connects to streamer but fails to > display any video. I get the following errors: > > main debug: `rtsp://11.0.0.30:8554/testStream' successfully opened > live555 debug: tk->rtpSource->hasBeenSynchronizedUsingRTCP() > main debug: ES_OUT_RESET_PCR called > main debug: Buffering 0% > main debug: Buffering 5% > main debug: Buffering 19% > main debug: Buffering 50% > main debug: Buffering 74% > main debug: Buffering 83% > main debug: Buffering 94% > main debug: Stream buffering done (1262 ms in 0 ms) > packetizer_h264 warning: waiting for SPS/PPS > packetizer_h264 warning: waiting for SPS/PPS > packetizer_h264 debug: found NAL_SPS (sps_id=0) > packetizer_h264 debug: found NAL_PPS (pps_id=0 sps_id=0) > main debug: Decoder buffering done in 1 ms > main error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased > to 1200 ms) > > Streaming from file using testH264VideoStreamer works fine. > > Any idea what can be wrong with my application would be greatly > appreciated. > > Thanks. > > Felix. > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > -------------------------------------------------------------------------------- > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From felix at embedded-sol.com Sun Oct 7 13:51:54 2012 From: felix at embedded-sol.com (Felix Radensky) Date: Sun, 07 Oct 2012 22:51:54 +0200 Subject: [Live-devel] Streaming in wireless ad-hoc network In-Reply-To: <9E80716B-78E2-48E5-8F0A-9996D8315F66@live555.com> References: <5071C609.5000300@embedded-sol.com> <9E80716B-78E2-48E5-8F0A-9996D8315F66@live555.com> Message-ID: <5071EB6A.2060001@embedded-sol.com> Hi Ross, Thanks for replying so promptly. >> Streaming from file using testH264VideoStreamer works fine. > > That's strange. Does your file have the same bit rate as your live > stream - i.e., was your file recorded simply by dumping the output > of your decoder (rather than, for example, taking one of the example > ".h264" files from our web site)? If so, then I can't explain what > you're seeing. > No, I've tried streaming slamtv10.264 downloaded from your site. I'll see if I can dump an encoder output to a file and stream it. Thanks. Felix. From felix at embedded-sol.com Sun Oct 7 14:00:08 2012 From: felix at embedded-sol.com (Felix Radensky) Date: Sun, 07 Oct 2012 23:00:08 +0200 Subject: [Live-devel] Streaming in wireless ad-hoc network In-Reply-To: References: <5071C609.5000300@embedded-sol.com> Message-ID: <5071ED58.1070606@embedded-sol.com> Hi Tayeb, Thanks for your input, I'll definitely try bridging. My kernel is 2.6, and adding brctl to the file system is not big deal. The wireless card on my device supports 802.11n, but so far I've only tried 802.11g, and both ends were able to synchronize at 54MBit/s. I think it should be sufficient, the video bandwidth is around 2Mbit/s. Felix. On 10/07/2012 08:49 PM, Meftah Tayeb wrote: > hello > what is your embedded distro ? > please try to create a bridge and atach your wlan interface to it > so the ip address will be in the bridge > if you have a 2.6 kernel, IGMP snooping will automaticaly be inabled > in your bridge > this may 90% solv your multicast over wireless issue > i am streaming 20channels over wireless but encoded in H.264/AAC > using MumuDVB without any issue at all > 802.11N is recomanded but 99.99% will not work in ad-hoc mode > thank you > ----- Original Message ----- From: "Felix Radensky" > > To: "LIVE555 Streaming Media - development & use" > > Sent: Sunday, October 07, 2012 9:12 PM > Subject: [Live-devel] Streaming in wireless ad-hoc network > > >> Hi, >> >> I'm having a real trouble getting live555 based streamer work in >> wireless >> ad-hoc network. The same streamer works fine in wired and managed >> wireless networks. >> >> My setup consists of embedded device and Linux based laptop. >> The live555 application runs on embedded device and streams >> live H.264 video over multicast. Video resolution is 640x480, frame >> rate is 30 FPS. VLC on laptop connects to streamer but fails to >> display any video. I get the following errors: >> >> main debug: `rtsp://11.0.0.30:8554/testStream' successfully opened >> live555 debug: tk->rtpSource->hasBeenSynchronizedUsingRTCP() >> main debug: ES_OUT_RESET_PCR called >> main debug: Buffering 0% >> main debug: Buffering 5% >> main debug: Buffering 19% >> main debug: Buffering 50% >> main debug: Buffering 74% >> main debug: Buffering 83% >> main debug: Buffering 94% >> main debug: Stream buffering done (1262 ms in 0 ms) >> packetizer_h264 warning: waiting for SPS/PPS >> packetizer_h264 warning: waiting for SPS/PPS >> packetizer_h264 debug: found NAL_SPS (sps_id=0) >> packetizer_h264 debug: found NAL_PPS (pps_id=0 sps_id=0) >> main debug: Decoder buffering done in 1 ms >> main error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay >> increased to 1200 ms) >> >> Streaming from file using testH264VideoStreamer works fine. >> >> Any idea what can be wrong with my application would be greatly >> appreciated. >> >> Thanks. >> >> Felix. >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 7404 (20120821) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> > > > -------------------------------------------------------------------------------- > > > >> _______________________________________________ >> live-devel mailing list >> live-devel at lists.live555.com >> http://lists.live555.com/mailman/listinfo/live-devel >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 7404 (20120821) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From kingaceck at 163.com Sun Oct 7 19:56:39 2012 From: kingaceck at 163.com (kingaceck) Date: Mon, 8 Oct 2012 10:56:39 +0800 Subject: [Live-devel] testMPEG1or2AudioVideoStreamer issue Message-ID: <201210081055056407620@163.com> Hi I use testMPEG1or2AudioVideoStreamer to streams mpg file to the multicast group 239.255.42.42, port 6666/6667 (for the audio stream) and 8888/8889 (for the video stream). When the client(the ip is 129.1.5.222) connect to the server with vlc(using the url rtsp://129.1.5.156/testStream) I run ping command(ping 129.1.5.222 -t) and there are many "time out" message: C:\Documents and Settings\Administrator>ping 129.1.5.222 -t Pinging 129.1.5.222 with 32 bytes of data: Request timed out. Request timed out. Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. I close the vlc and then run ping command(ping 129.1.5.222 -t), It becomes ok: C:\Documents and Settings\Administrator>ping 129.1.5.222 -t Pinging 129.1.5.222 with 32 bytes of data: Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 Reply from 129.1.5.222: bytes=32 time<1ms TTL=128 I try many times like this.The result is the network becoms very bad when client connecting to the testMPEG1or2AudioVideoStreamer server using url rtsp://129.1.5.156/testStream. If client connect to the multicast group 239.255.42.42 directly using url rtp://239.255.42.42:6666 the client can receive audio stream and the network also is OK. Why the network becomes so bad when client connecting to the testMPEG1or2AudioVideoStreamer server ?(caused a broadcast strom?) Please help me. 2012-10-08 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Mon Oct 8 01:41:13 2012 From: kingaceck at 163.com (kingaceck) Date: Mon, 8 Oct 2012 16:41:13 +0800 Subject: [Live-devel] modify live555ProxyServer to support multicast Message-ID: <201210081640147969743@163.com> Hi I have read the live555ProxyServer code,but I find It doesn't support multicast. I want to modify this project to support multicast so that clients can receive the data using multicast(url like this rtsp://129.1.5.1:554/proxyStream).What can I do? Please show me the details step by step. Thank you very much. 2012-10-08 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb at tmxvoip.com Mon Oct 8 04:46:23 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Mon, 8 Oct 2012 14:46:23 +0300 Subject: [Live-devel] modify live555ProxyServer to support multicast References: <201210081640147969743@163.com> Message-ID: <0B571AB0DFBC49D4AFD481B63C0FDBED@work> this ip is not Multicast 129.X.X.X is Unicast Multicast is 224.0.0.0|239.255.255.255. and i belieuv The Live555 Proxy server support both Multicast and Unicast ----- Original Message ----- From: "kingaceck" To: "live-devel" Sent: Monday, October 08, 2012 11:41 AM Subject: [Live-devel] modify live555ProxyServer to support multicast > Hi > I have read the live555ProxyServer code,but I find It doesn't support > multicast. I want to modify this project to support multicast so that > clients can receive the data using multicast(url like this > rtsp://129.1.5.1:554/proxyStream).What can I do? Please show me the > details step by step. > > Thank you very much. > > > > > 2012-10-08 > > > > kingaceck > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > -------------------------------------------------------------------------------- > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From finlayson at live555.com Mon Oct 8 07:10:46 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Oct 2012 07:10:46 -0700 Subject: [Live-devel] modify live555ProxyServer to support multicast In-Reply-To: <0B571AB0DFBC49D4AFD481B63C0FDBED@work> References: <201210081640147969743@163.com> <0B571AB0DFBC49D4AFD481B63C0FDBED@work> Message-ID: <7D1D91BE-5E63-4DDB-8918-673D2C5508D7@live555.com> > this ip is not Multicast > 129.X.X.X is Unicast That's true, but irrelevant to "kingaceck"s question. He was asking how to write a RTSP proxy that relays from a (unicast or multicast) 'back-end' RTSP stream to a multicast 'front-end' RTSP stream. This front-end RTSP stream would be accessed via unicast (because RTSP is a TCP-based protocol), but the stream itself would be multicast. (Note, for example, that our "test*Streamer" demo applications also send multicast streams that can be (and in some cases, must be) accessed via RTSP.) In contrast, our "LIVE555 Proxy Server" relays from a (unicast or multicast) 'back-end' RTSP stream to a (actually, one or more) *unicast* 'front-end' streams. The "Subject:" line of this thread is wrong, because neither the "LIVE555 Proxy Server" (nor the "ProxyServerMediaSession" class in particular) can be 'modified' to get what "kingaceck" wants. They're just too different. Instead, he would need to write his own "PassiveServerMediaSubsession" subclass, combined with a "ServerMediaSession" (subclass), and a "RTSPServer" (as illustrated by the "test*Streamer" demo applications). These would implement the multicast 'front-end' stream. He would then need to use a "RTSPClient" (perhaps a "RTSPClient" subclass) to implement the reception of the 'back-end' stream. However, this is sufficiently complicated that I'm certainly not going to "show (him) the details step by step" as he requested (especially since he uses an unprofessional email address). He's going to have to work out the (many) details himself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb at tmxvoip.com Mon Oct 8 09:36:18 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Mon, 8 Oct 2012 19:36:18 +0300 Subject: [Live-devel] modify live555ProxyServer to support multicast References: <201210081640147969743@163.com> <0B571AB0DFBC49D4AFD481B63C0FDBED@work> <7D1D91BE-5E63-4DDB-8918-673D2C5508D7@live555.com> Message-ID: <4CBF9F7776D24EA2855E90738C3A0FF1@work> True, ross so he maybe asked his question with a strange maner. Anyway, thank you for that. you allready explained him a lot;-) ----- Original Message ----- From: "Ross Finlayson" To: "LIVE555 Streaming Media - development & use" Sent: Monday, October 08, 2012 5:10 PM Subject: Re: [Live-devel] modify live555ProxyServer to support multicast > this ip is not Multicast > 129.X.X.X is Unicast That's true, but irrelevant to "kingaceck"s question. He was asking how to write a RTSP proxy that relays from a (unicast or multicast) 'back-end' RTSP stream to a multicast 'front-end' RTSP stream. This front-end RTSP stream would be accessed via unicast (because RTSP is a TCP-based protocol), but the stream itself would be multicast. (Note, for example, that our "test*Streamer" demo applications also send multicast streams that can be (and in some cases, must be) accessed via RTSP.) In contrast, our "LIVE555 Proxy Server" relays from a (unicast or multicast) 'back-end' RTSP stream to a (actually, one or more) *unicast* 'front-end' streams. The "Subject:" line of this thread is wrong, because neither the "LIVE555 Proxy Server" (nor the "ProxyServerMediaSession" class in particular) can be 'modified' to get what "kingaceck" wants. They're just too different. Instead, he would need to write his own "PassiveServerMediaSubsession" subclass, combined with a "ServerMediaSession" (subclass), and a "RTSPServer" (as illustrated by the "test*Streamer" demo applications). These would implement the multicast 'front-end' stream. He would then need to use a "RTSPClient" (perhaps a "RTSPClient" subclass) to implement the reception of the 'back-end' stream. However, this is sufficiently complicated that I'm certainly not going to "show (him) the details step by step" as he requested (especially since he uses an unprofessional email address). He's going to have to work out the (many) details himself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------------------------------------------------------------------------- > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From andrey.shadrin at sprecord.ru Mon Oct 8 23:35:57 2012 From: andrey.shadrin at sprecord.ru (=?UTF-8?B?0JDQvdC00YDQtdC5INCo0LDQtNGA0LjQvQ==?=) Date: Tue, 09 Oct 2012 10:35:57 +0400 Subject: [Live-devel] Why proxy server automatically send "PLAY"? Message-ID: <5073C5CD.4000101@sprecord.ru> Hi Ross, After sending the proxy command "SETUP", it sends "SETUP" to source, and after that immediately sends "PLAY", without the command "PLAY" on the server side. Why before sending "PLAY" to source, proxydoes not expect this command froma server-side proxy server? From finlayson at live555.com Tue Oct 9 22:37:17 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Oct 2012 22:37:17 -0700 Subject: [Live-devel] Why proxy server automatically send "PLAY"? In-Reply-To: <5073C5CD.4000101@sprecord.ru> References: <5073C5CD.4000101@sprecord.ru> Message-ID: <8D696677-5886-40FD-94D8-437B157C8316@live555.com> > After sending the proxy command "SETUP", it sends "SETUP" to source, and after that immediately sends "PLAY", without the command "PLAY" on the server side. > > Why before sending "PLAY" to source, proxydoes not expect this command froma server-side proxy server? Because (unlike "SETUP") the "PLAY" command from the front-end client does not signal the "OnDemandServerMediaSubsession" (sub)class at all. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Wed Oct 10 02:42:44 2012 From: kingaceck at 163.com (kingaceck) Date: Wed, 10 Oct 2012 17:42:44 +0800 Subject: [Live-devel] modify live555ProxyServer to support multicast Message-ID: <201210101742427960002@163.com> Thanks for your reply. Your have replied : That's true, but irrelevant to "kingaceck"s question. He was asking how to write a RTSP proxy that relays from a (unicast or multicast) 'back-end' RTSP stream to a multicast 'front-end' RTSP stream. This front-end RTSP stream would be accessed via unicast (because RTSP is a TCP-based protocol), but the stream itself would be multicast. (Note, for example, that our "test*Streamer" demo applications also send multicast streams that can be (and in some cases, must be) accessed via RTSP.) In contrast, our "LIVE555 Proxy Server" relays from a (unicast or multicast) 'back-end' RTSP stream to a (actually, one or more) *unicast* 'front-end' streams. The "Subject:" line of this thread is wrong, because neither the "LIVE555 Proxy Server" (nor the "ProxyServerMediaSession" class in particular) can be 'modified' to get what "kingaceck" wants. They're just too different. Instead, he would need to write his own "PassiveServerMediaSubsession" subclass, combined with a "ServerMediaSession" (subclass), and a "RTSPServer" (as illustrated by the "test*Streamer" demo applications). These would implement the multicast 'front-end' stream. He would then need to use a "RTSPClient" (perhaps a "RTSPClient" subclass) to implement the reception of the 'back-end' stream. However, this is sufficiently complicated that I'm certainly not going to "show (him) the details step by step" as he requested (especially since he uses an unprofessional email address). He's going to have to work out the (many) details himself. Now I want to modify ProxyServerMediaSubsession to inherit PassiveServerMediaSubsession(not OnDemandServerMediaSubsession ). Using createNewRTPSink to create a "sink" before "doEventLoop ".Is it probably to support multicast using this way? Thank you very much! 2012-10-10 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Wed Oct 10 11:59:06 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Wed, 10 Oct 2012 20:59:06 +0200 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <506C3C3A0200004D000749A1@pta-emo.csir.co.za> <737D7C5A-DC55-455E-ABAE-91126611BF38@live555.com> <5071747A0200004D00074DD1@pta-emo.csir.co.za> Message-ID: <5075E19A0200004D000752E5@pta-emo.csir.co.za> Hi Ross, We upgraded the server side to the live555 with the fix, but the issue continues to happen. > Does this problem happen *always* whenever you stream from this particular server (in RTP/RTCP-over-TCP mode), or only *sometimes* from this server (e.g., only when the network is congested)? At the moment, it happens every time when *I* try to connect with the android device which is connected to the Internet over wifi. Some more info, not sure if it helps at all: I'm currently located in Germany, and the server is in South Africa. With the upgrade my colleagues in South Africa have a much lower failure rate, say around 1 out of every 10 times. At least it's consistently failing on my end so I'm hoping that will make it easier to track down the issue. > If the problem still happens - even after you've upgraded your server - then please add the line #define DEBUG_RECEIVE 1 to the start of "liveMedia/RTPInterface.cpp" (for your client), recompile your client, and send us another log (when you see the error happening again). Here's an excerpt of the log with DEBUG_RECEIVE: D/VLC (21494): [0x434770]: live555 demux version 2012.10.04 D/VLC (21494): [0x434770]: live555 demux RTP subsession 'video/H263-1998' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::registerRTPInterface(channel D/live555 (21494): 0 D/live555 (21494): ): isFirstRegistration D/live555 (21494): 1 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::registerRTPInterface(channel D/live555 (21494): 1 D/live555 (21494): ): isFirstRegistration D/live555 (21494): 0 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::registerRTPInterface(channel D/live555 (21494): 1 D/live555 (21494): ): isFirstRegistration D/live555 (21494): 0 D/live555 (21494): D/VLC (21494): [0x427ff8]: main input selecting program id=0 D/VLC (21494): [0x434770]: live555 demux RTP subsession 'audio/AMR' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::registerRTPInterface(channel D/live555 (21494): 2 D/live555 (21494): ): isFirstRegistration D/live555 (21494): 0 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::registerRTPInterface(channel D/live555 (21494): 3 D/live555 (21494): ): isFirstRegistration D/live555 (21494): 0 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::registerRTPInterface(channel D/live555 (21494): 3 D/live555 (21494): ): isFirstRegistration D/live555 (21494): 0 D/live555 (21494): D/VLC (21494): [0x434770]: live555 demux setup start: 0.000000 stop:0.000000 D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): No handler proc for "rtpInterface" for channel D/live555 (21494): 0 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 135 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 104 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 86 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 217 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 106 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 253 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 250 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 183 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 247 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): No handler proc for "rtpInterface" for channel D/live555 (21494): 0 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): No handler proc for "rtpInterface" for channel D/live555 (21494): 2 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 24 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 85 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): No handler proc for "rtpInterface" for channel D/live555 (21494): 0 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw '$' D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::tcpReadHandler(): Saw nonexistent stream channel id: D/live555 (21494): 246 D/live555 (21494): ... ... E/VLC (21494): [0x434770]: live555 demux RTSP PLAY failed RTSP response was truncated. Increase "RTSPClient::responseBufferSize" D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::deregisterRTPInterface(channel D/live555 (21494): 1 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::deregisterRTPInterface(channel D/live555 (21494): 0 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::deregisterRTPInterface(channel D/live555 (21494): 3 D/live555 (21494): D/live555 (21494): SocketDescriptor(socket D/live555 (21494): 47 D/live555 (21494): )::deregisterRTPInterface(channel D/live555 (21494): 2 D/live555 (21494): Any idea what might be going wrong? Thanks for your help in investigating this. I'd be glad to add any other debugging info if that helps. Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From tayeb at tmxvoip.com Wed Oct 10 10:22:39 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Wed, 10 Oct 2012 20:22:39 +0300 Subject: [Live-devel] modify live555ProxyServer to support multicast References: <201210101742427960002@163.com> Message-ID: <6CC04F3188EE4B868C0D0AE168163AC7@work> please dont start a new discution to continu your old discution thank ross, kiss my ass if i'm wrong. ----- Original Message ----- From: "kingaceck" To: "live-devel" Sent: Wednesday, October 10, 2012 12:42 PM Subject: [Live-devel] modify live555ProxyServer to support multicast > Thanks for your reply. > Your have replied : > That's true, but irrelevant to "kingaceck"s question. He was asking how > to write a RTSP proxy that relays from a (unicast or multicast) 'back-end' > RTSP stream to a multicast 'front-end' RTSP stream. This front-end RTSP > stream would be accessed via unicast (because RTSP is a TCP-based > protocol), but the stream itself would be multicast. (Note, for example, > that our "test*Streamer" demo applications also send multicast streams > that can be (and in some cases, must be) accessed via RTSP.) > > In contrast, our "LIVE555 Proxy Server" relays from a (unicast or > multicast) 'back-end' RTSP stream to a (actually, one or more) *unicast* > 'front-end' streams. > > The "Subject:" line of this thread is wrong, because neither the "LIVE555 > Proxy Server" (nor the "ProxyServerMediaSession" class in particular) can > be 'modified' to get what "kingaceck" wants. They're just too different. > Instead, he would need to write his own "PassiveServerMediaSubsession" > subclass, combined with a "ServerMediaSession" (subclass), and a > "RTSPServer" (as illustrated by the "test*Streamer" demo applications). > These would implement the multicast 'front-end' stream. He would then > need to use a "RTSPClient" (perhaps a "RTSPClient" subclass) to implement > the reception of the 'back-end' stream. > > However, this is sufficiently complicated that I'm certainly not going to > "show (him) the details step by step" as he requested (especially since he > uses an unprofessional email address). He's going to have to work out the > (many) details himself. > > > Now I want to modify ProxyServerMediaSubsession to inherit > PassiveServerMediaSubsession(not OnDemandServerMediaSubsession ). Using > createNewRTPSink to create a "sink" before "doEventLoop ".Is it probably > to support multicast using this way? > > Thank you very much! > > > 2012-10-10 > > > > kingaceck > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > -------------------------------------------------------------------------------- > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From finlayson at live555.com Wed Oct 10 12:22:44 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Oct 2012 12:22:44 -0700 Subject: [Live-devel] modify live555ProxyServer to support multicast In-Reply-To: <201210101742427960002@163.com> References: <201210101742427960002@163.com> Message-ID: <40D8AAF9-5CBF-425F-A5AC-BBEFCD89FC30@live555.com> > Now I want to modify ProxyServerMediaSubsession to inherit PassiveServerMediaSubsession(not OnDemandServerMediaSubsession ). As is stated clearly in the FAQ (that everyone was asked to read before posting to the mailing list!), you should not "modify" the existing code. Instead, you would write your own new class (called, e.g., "myProxyServerMediaSubsession") that inherits from "PassiveServerMediaSubsession" (and does whatever you want). However, I don't have the time to explain to you the (many) details of how to do this, so please don't ask. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 10 12:26:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Oct 2012 12:26:54 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <5075E19A0200004D000752E5@pta-emo.csir.co.za> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <506C3C3A0200004D000749A1@pta-emo.csir.co.za> <737D7C5A-DC55-455E-ABAE-91126611BF38@live555.com> <5071747A0200004D00074DD1@pta-emo.csir.co.za> <5075E19A0200004D000752E5@pta-emo.csir.co.za> Message-ID: OK, your log suggests that 'incomplete' data is being received over TCP (by the client), which implies (assuming that your client+server OS's TCP/IP implementation is correct) that some of the server's writes to the TCP socket are failing. You can check this by updating your *server* code as follows: - add #define DEBUG_SEND 1 to "liveMedia/RTPInterface.cpp" - recompile, then rerun your server. If you ever see the error message sendRTPOverTCP: failed! then this shows that the server's writes to the TCP socket are eventually overflowing the OS's internal buffer (which should be at least 50 kBytes), which in turn implies that your stream's bitrate is greater than the data capacity of the TCP connection. In this case there is nothing that you can do other than decrease the bitrate of your stream. Everyone needs to understand that streaming RTP-over-TCP is something that you should do *only* when you are streaming over a firewall that does not pass UDP packets. You should not think that just because TCP is a 'reliable' transport protocol, that you can use it to ensure 100% delivery of all of the stream data. This may happen if the stream's bitrate is less than the capacity of the TCP connection, but if the stream's bitrate exceeds the capacity of the TCP connection, then you *will* get data loss (and in an inefficient way, because it won't occur on RTP packet boundaries, as it would if you were streaming via RTP/UDP). This is the difference between streaming and 'file/webpage downloading', for example. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Wed Oct 10 13:44:45 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Wed, 10 Oct 2012 20:44:45 +0000 Subject: [Live-devel] Properly shutting down stream after TEARDOWN Message-ID: Lately I've seen some random exceptions when streams are being shut down. I believe these were introduced when I changed the code so it waits for a TEARDOWN response. This was btw done as Cisco mentioned their server requires that. I'm probably doing something wrong, as it appears the error happens in, or are related to, the TEARDOWN response handler. With the shutdownStream() function in testRTSPClient as a model I basically added a response handler to the sendTeardownCommand() and added an additional cleanup function that should take care of the final cleanup and properly close the rtspClient. - Can't I assume the rtspClient is valid after TEARDOWN? - If not, how should I then properly execute Medium::close(rtspClient)? - In cleanUpStream() I delete all event triggers. This needs to be done, right, or is it somehow that's taken care of automatically? The exception has never occurred while stepping through the code, but the exception appears to occur right after sendTeardownCommand() has been called. Sample code below. Is that the proper way to clean up? void continueAfterTEARDOWN(RTSPClient* rtspClient, int resultCode, char* resultString) { if (resultCode != 0) { UsageEnvironment& env = rtspClient->envir(); env << *rtspClient << "TEARDOWN result code: " << resultCode << ".\n"; } cleanUpStream(rtspClient); } void shutdownStream(RTSPClient* rtspClient, int exitCode) { UsageEnvironment& env = rtspClient->envir(); StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs; // First, check whether any subsessions have still to be closed: if (scs.session != NULL) { Boolean someSubsessionsWereActive = False; MediaSubsessionIterator iter(*scs.session); MediaSubsession* subsession; while ((subsession = iter.next()) != NULL) { if (subsession->sink != NULL) { Medium::close(subsession->sink); subsession->sink = NULL; if (subsession->rtcpInstance() != NULL) { // in case the server sends a RTCP "BYE" while handling "TEARDOWN" subsession->rtcpInstance()->setByeHandler(NULL, NULL); } someSubsessionsWereActive = True; } } if (someSubsessionsWereActive) { // Send a RTSP "TEARDOWN" command, to tell the server to shutdown the stream. // We now want to handle the response. rtspClient->sendTeardownCommand(*scs.session, continueAfterTEARDOWN); } else { cleanUpStream(rtspClient); } } else { cleanUpStream(rtspClient); } } // Aka shutdownStream part 2. We do the final cleanup in a separate function as we // want to wait until we receive the TEARDOWN response. void cleanUpStream(RTSPClient* rtspClient) { UsageEnvironment& env = rtspClient->envir(); env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStart StreamEvent); env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStopS treamEvent); env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->mySeekA bsoluteEvent); env << *rtspClient << "Closing the stream.\n"; Medium::close(rtspClient); // Note that this will also cause this stream's "StreamClientState" structure to get reclaimed. } /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Wed Oct 10 20:44:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Oct 2012 20:44:59 -0700 Subject: [Live-devel] Properly shutting down stream after TEARDOWN In-Reply-To: References: Message-ID: <64A4A51F-CAF6-4511-A5CB-83AAC0837E72@live555.com> > Lately I've seen some random exceptions when streams are being shut down. I believe these were introduced when I changed the code so it waits for a TEARDOWN response. This was btw done as Cisco mentioned their server requires that. > BTW, that doesn't really make much sense, because after the server receives a "TEARDOWN" request, it has no further communication from that client - other than the client closing the connection. But the server needs to be prepared for the client closing the connection at any time anyway. So the server really shouldn't care whether or not the client waits for a response to the "TEARDOWN". But anyway: > I'm probably doing something wrong, as it appears the error happens in, or are related to, the TEARDOWN response handler. > > With the shutdownStream() function in testRTSPClient as a model I basically added a response handler to the sendTeardownCommand() and added an additional cleanup function that should take care of the final cleanup and properly close the rtspClient. > > - Can't I assume the rtspClient is valid after TEARDOWN? > Yes, the "RTSPClient" object remains valid until you call "Medium::close()" on it. So therefore, make sure that you don't call "Medium::close()" until *after* you've received the response to the "TEARDOWN". (Note that the "testRTSPClient" code calls "Medium::close()" on "rtspClient" immediately after sending the "TEARDOWN" command, so obviously you'll need to change that in your code.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 10 22:21:50 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Oct 2012 22:21:50 -0700 Subject: [Live-devel] Properly shutting down stream after TEARDOWN In-Reply-To: References: Message-ID: <7A926D13-A005-4C96-B6B8-D1D5E4A323E4@live555.com> I realized that I had forgotten to answer this question: > - In cleanUpStream() I delete all event triggers. This needs to be done, right, or is it somehow that's taken care of automatically? > Yes, although you don't need to do this if you know that - at this time - the separate 'event triggering' thread will no longer be calling "triggerEvent()". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam at sammachin.com Thu Oct 11 08:48:46 2012 From: sam at sammachin.com (Sam Machin) Date: Thu, 11 Oct 2012 16:48:46 +0100 Subject: [Live-devel] PlaySIP SegFault Message-ID: I've just come across playSIP and it seems like its exactly what I've been looking for, however I can't get it to run, I've tried installing it onto an ubunutu 12.04 server on EC2 using the livemedia-utils package and also building from source on my iMac running 10.7, however both times I try to start it with a command "playsip sip:1234 at sip.sammachin.com" it just segfaults. Any help welcome? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 11 11:04:35 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Oct 2012 11:04:35 -0700 Subject: [Live-devel] PlaySIP SegFault In-Reply-To: References: Message-ID: > I've tried installing it onto an ubunutu 12.04 server on EC2 using the livemedia-utils package and also building from source on my iMac running 10.7, however both times I try to start it with a command "playsip sip:1234 at sip.sammachin.com" it just segfaults. > > Any help welcome? Thanks for the report. I've now installed a new version (2012.10.11) of the "LIVE555 Streaming Media" software that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbatra18 at gmail.com Thu Oct 11 08:20:12 2012 From: tbatra18 at gmail.com (Tarun Batra) Date: Thu, 11 Oct 2012 20:50:12 +0530 Subject: [Live-devel] How to re transmit Message-ID: Hello Sir, I have implemented ?testOnDemandRTSPServer? on my machine which receives h264 transport stream from my streamer application. Is there any way to re transmit this received stream from streamer, to my RTSP clients with different fame rates? As some of my RTSP clients do not have sufficient bandwidth to receive stream with high frame rate. My streamer uses MPEG1or2VideoStreamDiscreteFramer to stream a video from digital camera. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic.nadeau at transport.alstom.com Fri Oct 12 04:15:21 2012 From: frederic.nadeau at transport.alstom.com (NADEAU Frederic -EXT) Date: Fri, 12 Oct 2012 11:15:21 +0000 Subject: [Live-devel] PlaySIP SegFault In-Reply-To: References: Message-ID: <887184C35EAC384EA0867D9A0D3C6B66AD8F29@041-DB3MPN1-101.041d.mgd.msft.net> There is another error in playsip. To fix that issue, we used : # playSIP -u nouser nopass 10.0.0.1 sip :100 at 10.0.0.1, I didn't look at the 2012-10-11 fix, but from what I know the issue is with the authenticator. But there is more. Latest code(as of 2012-10-11) gives this : (sorry for the long post, comments continue in middle and at the end) ################################################################################################ fnadeau at ip-10-xxx-xxx-xxx:~/live/testProgs> ./playSIP -Q sip:8355 at ideasip.com Sending request: INVITE sip:8355 at ideasip.com SIP/2.0 From: 8355 ;tag=433402263 Via: SIP/2.0/UDP 10.6.161.115:55386 To: sip:8355 at ideasip.com Contact: sip:8355 at 10.6.161.115:55386 Call-ID: 984943604 at 10.6.161.115 CSeq: 1 INVITE Content-Type: application/sdp User-Agent: playSIP (LIVE555 Streaming Media v2012.10.11) Content-Length: 115 v=0 o=- 984943604 0 IN IP4 10.6.161.115 s=playSIP session c=IN IP4 10.6.161.115 t=0 0 m=audio 8000 RTP/AVP 0 Received INVITE response: SIP/2.0 100 trying -- your call is important to us From: 8355 ;tag=433402263 Via: SIP/2.0/UDP 10.6.161.115:55386;received=50.16.169.79 To: sip:8355 at ideasip.com Call-ID: 984943604 at 10.6.161.115 CSeq: 1 INVITE Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Warning: 392 208.97.25.11:5060 "Noisy feedback tells: pid=6093 req_src_ip=50.16.169.79 req_src_port=55386 in_uri=sip:8355 at ideasip.com out_uri=sip:9797918005558355 at 208.97.25.12:5090 via_cnt==1" Received INVITE response: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.6.161.115:55386;received=50.16.169.79 Record-Route: From: 8355 ;tag=433402263 To: sip:8355 at ideasip.com;tag=as1dd4047f Call-ID: 984943604 at 10.6.161.115 CSeq: 1 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Contact: Content-Type: application/sdp Content-Length: 182 v=0 o=root 6571 6571 IN IP4 208.97.25.12 s=session c=IN IP4 208.97.25.12 t=0 0 m=audio 19840 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Opened URL "sip:8355 at ideasip.com", returning a SDP description: v=0 o=- 984943604 0 IN IP4 10.6.161.115 s=playSIP session c=IN IP4 10.6.161.115 t=0 0 m=audio 8000 RTP/AVP 0 Created receiver for "audio/PCMU" subsession (client ports 47616-47617) Setup "audio/PCMU" subsession (client ports 47616-47617) Created output file: "audio-PCMU-1" Sending request: ACK sip:8355 at ideasip.com SIP/2.0 From: 8355 ;tag=433402263 Via: SIP/2.0/UDP 10.6.161.115:55386 To: sip:8355 at ideasip.com;tag=as1dd4047f Call-ID: 984943604 at 10.6.161.115 CSeq: 1 ACK Content-Length: 0 Started playing session Receiving streamed data (signal with "kill -HUP 1502" or "kill -USR1 1502" to terminate)... Got shutdown signal begin_QOS_statistics subsession audio/PCMU num_packets_received 0 num_packets_lost 0 elapsed_measurement_time 8.000067 kBytes_received_total 0.000000 measurement_sampling_interval_ms 1000 kbits_per_second_min unavailable kbits_per_second_ave unavailable kbits_per_second_max unavailable packet_loss_percentage_min 100.000000 packet_loss_percentage_ave 100.000000 packet_loss_percentage_max 100.000000 end_QOS_statistics Sending request: BYE sip:8355 at ideasip.com SIP/2.0 From: 8355 ;tag=433402263 Via: SIP/2.0/UDP 10.6.161.115:55386 To: sip:8355 at ideasip.com;tag=as1dd4047f Call-ID: 984943604 at 10.6.161.115 CSeq: 2 BYE Content-Length: 0 fnadeau at ip-10-xxx-xxx-xxx:~/live/testProgs> ls -l audio-PCMU-1 -rw-r--r-- 1 fnadeau users 0 Oct 12 10:52 audio-PCMU-1 ################################################################################################ Notice that the audio as 0 byte. The client port (from line Created receiver for "audio/PCMU" subsession (client ports 47616-47617)) is wrong. The SDP we send says we expect audio on port 8000. We use an old build (don't ask) and get this as a result (we use the fix above to avoid segfault) : ################################################################################################ fnadeau at ip-10-xxx-xxx-xxx:~/Live555/testProgs> ./playSIP -Q -u nouser nopass ideasip.com sip:8355 at ideasip.com Sending request: INVITE sip:8355 at ideasip.com SIP/2.0 From: nouser ;tag=146126391 Via: SIP/2.0/UDP 10.6.161.115:44716 To: sip:8355 at ideasip.com Contact: sip:nouser at 10.6.161.115:44716 Call-ID: 1687940000 at 10.6.161.115 CSeq: 1 INVITE Content-Type: application/sdp User-Agent: playSIP (LIVE555 Streaming Media v2010.09.10) Content-length: 116 v=0 o=- 1687940000 0 IN IP4 10.6.161.115 s=playSIP session c=IN IP4 10.6.161.115 t=0 0 m=audio 8000 RTP/AVP 0 Received INVITE response: SIP/2.0 100 trying -- your call is important to us From: nouser ;tag=146126391 Via: SIP/2.0/UDP 10.6.161.115:44716;received=50.16.169.79 To: sip:8355 at ideasip.com Call-ID: 1687940000 at 10.6.161.115 CSeq: 1 INVITE Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Warning: 392 208.97.25.11:5060 "Noisy feedback tells: pid=6090 req_src_ip=50.16.169.79 req_src_port=44716 in_uri=sip:8355 at ideasip.com out_uri=sip:9797918005558355 at 208.97.25.12:5090 via_cnt==1" Received INVITE response: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.6.161.115:44716;received=50.16.169.79 Record-Route: From: nouser ;tag=146126391 To: sip:8355 at ideasip.com;tag=as5f442dd5 Call-ID: 1687940000 at 10.6.161.115 CSeq: 1 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Contact: Content-Type: application/sdp Content-Length: 182 v=0 o=root 6571 6571 IN IP4 208.97.25.12 s=session c=IN IP4 208.97.25.12 t=0 0 m=audio 19348 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Opened URL "sip:8355 at ideasip.com", returning a SDP description: v=0 o=- 1687940000 0 IN IP4 10.6.161.115 s=playSIP session c=IN IP4 10.6.161.115 t=0 0 m=audio 8000 RTP/AVP 0 Created receiver for "audio/PCMU" subsession (client ports 8000-8001) Scanning: [v=0] Scanning: [o=root 6571 6571 IN IP4 208.97.25.12] Scanning: [s=session] Scanning: [c=IN IP4 208.97.25.12] Scanning: [t=0 0] Scanning: [m=audio 19348 RTP/AVP 0] Scanning: [a=rtpmap:0 PCMU/8000] Scanning: [a=silenceSupp:off - - - -] Scanning: [a=ptime:20] Scanning: [a=sendrecv] Scanning: [] Setup "audio/PCMU" subsession (client ports 8000-8001) Created output file: "audio-PCMU-1" Sending request: ACK sip:8355 at ideasip.com SIP/2.0 From: nouser ;tag=146126391 Via: SIP/2.0/UDP 10.6.161.115:44716 To: sip:8355 at ideasip.com;tag=as5f442dd5 Call-ID: 1687940000 at 10.6.161.115 CSeq: 1 ACK Content-length: 0 Started playing session Receiving streamed data (signal with "kill -HUP 1504" or "kill -USR1 1504" to terminate)... Got shutdown signal begin_QOS_statistics subsession audio/PCMU num_packets_received 184 num_packets_lost 0 elapsed_measurement_time 10.001158 kBytes_received_total 29.440000 measurement_sampling_interval_ms 1000 kbits_per_second_min 0.000000 kbits_per_second_ave 23.549273 kbits_per_second_max 64.000064 packet_loss_percentage_min 0.000000 packet_loss_percentage_ave 0.000000 packet_loss_percentage_max 0.000000 inter_packet_gap_ms_min 16.417000 inter_packet_gap_ms_ave 19.888000 inter_packet_gap_ms_max 23.798000 end_QOS_statistics Sending request: BYE sip:8355 at ideasip.com SIP/2.0 From: nouser ;tag=146126391 Via: SIP/2.0/UDP 10.6.161.115:44716 To: sip:8355 at ideasip.com;tag=as5f442dd5 Call-ID: 1687940000 at 10.6.161.115 CSeq: 2 BYE Content-length: 0 fnadeau at ip-10-xxx-xxx-xxx:~/Live555/testProgs> ls -l audio-PCMU-1 -rw-r--r-- 1 fnadeau users 29440 Oct 12 10:53 audio-PCMU-1 ################################################################################################ It is a slightly modified version, mostly on printout info. This is run on EC2 as well (SUSE, but does not really matter). The SIP is publicaly available. The audio says : sorry you don't have enough credit to call this number. Could be better, but it is a test after all. Since we are still using a old version, I couldn't port our modification to the latest version and test. I didn't have time to trace down the issue any further. Fr?d?ric Nadeau De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : 11 octobre 2012 14:05 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] PlaySIP SegFault I've tried installing it onto an ubunutu 12.04 server on EC2 using the livemedia-utils package and also building from source on my iMac running 10.7, however both times I try to start it with a command "playsip sip:1234 at sip.sammachin.com" it just segfaults. Any help welcome? Thanks for the report. I've now installed a new version (2012.10.11) of the "LIVE555 Streaming Media" software that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 12 10:20:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Oct 2012 10:20:54 -0700 Subject: [Live-devel] PlaySIP SegFault In-Reply-To: <887184C35EAC384EA0867D9A0D3C6B66AD8F29@041-DB3MPN1-101.041d.mgd.msft.net> References: <887184C35EAC384EA0867D9A0D3C6B66AD8F29@041-DB3MPN1-101.041d.mgd.msft.net> Message-ID: > There is another error in playsip. [...] > Notice that the audio as 0 byte. The client port (from line Created receiver for "audio/PCMU" subsession (client ports 47616-47617)) is wrong. The SDP we send says we expect audio on port 8000. I've just installed a new version (2012.10.12) of the "LIVE555 Streaming Media" software that fixes this. Thanks for the report. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 12 10:31:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Oct 2012 10:31:33 -0700 Subject: [Live-devel] Is it possible to override the RTP port chosen by the server? In-Reply-To: <42B632EF4EFA4C5E9FB204B3F9DD7287@CSystemDev> References: <42B632EF4EFA4C5E9FB204B3F9DD7287@CSystemDev> Message-ID: <2DA0A90B-0E8C-4383-8375-CE7BCA3DD644@live555.com> > Some Samsung cameras (SNB-5000, SND-5080, SNO-5080) choose the RTP destination port; kindly, the Live555 RTSPClient respect this request. > Instead Samsung, unkindly, doens't let us disable this feature or set the desired port up via the camera's configuration web page; so sometimes two or more cameras (and all after power on) choose the same port: so some streams starve and other ones receive frames coming from two or more cameras. > > Could you please tell me if and where subclassing in order to make Live555 refuse the port chosen by the camera and answer with a port chosen by the OS (hoping the camera will accept the change FYI, I had to undo the change to the code that I made (back in version 2012.06.12) to ignore server-specified SDP port numbers (for unicast streams), because it was breaking our SIP client. Now, if you want the code to ignore SDP-specified port numbers, you can do so by adding -DIGNORE_UNICAST_SDP_PORTS=1 to the compile line (when compiling "liveMedia/MediaSession.cpp"). (Even better, though, would be to get Samsung to upgrade their cameras' firmware to allow their port number(s) to be configured by the user.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Fri Oct 12 02:13:17 2012 From: kingaceck at 163.com (kingaceck) Date: Fri, 12 Oct 2012 17:13:17 +0800 Subject: [Live-devel] relay the packet directly Message-ID: <201210121713151569448@163.com> Hi I am writing a RTSP proxy that relays from a (unicast or multicast) 'back-end' RTSP stream(AAC/H264) to a multicast 'front-end' RTSP stream.When received the packet that coming from 'back-end' RTSP server I want to relay the packet directly instead of to disassemble it and then generate new packet(like 'live555ProxyServer' does).I know How can I do to relay the incoming packet directly ? Thank you very much. 2012-10-12 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjh431 at gmail.com Fri Oct 12 03:24:47 2012 From: sjh431 at gmail.com (jhseo) Date: Fri, 12 Oct 2012 19:24:47 +0900 Subject: [Live-devel] Question about RTSP PAUSE / RESUME timestamp Message-ID: <049f01cda863$d0907850$71b168f0$@gmail.com> Hi. I have a question about RTSP PAUSE / RESUME timestamp. I'm using live555(ADTSAudioFileServerMediaSubsession.cpp & H264VideoStreamDiscreteFramer.cpp) If One video frame is truncated by PAUSE / RESUME request, how to use timestamp? RTP packet of a same frame's timestamps are same values, but uppercase doesn't same value in RTP packet.. (when it resumed, presetNextTimestamp( ) function is called..) Is it right solution?? Thanks for your interest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Sat Oct 13 04:11:53 2012 From: hackeron at gmail.com (Roman Gaufman) Date: Sat, 13 Oct 2012 12:11:53 +0100 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" Message-ID: I'm reading from a Sony IP cameras, I'm running: ./live/proxyServer/live555ProxyServer -t "rtsp://192.168.88.13/media/video1" I'm then trying to read the RTSP with: ./live/testProgs/openRTSP 'rtsp://192.168.0.2:554/proxyStream' After a while, the stream freezes and I'm getting: RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" I tried to increase this value in live/liveMedia/RTCP.cpp: static unsigned const maxRTCPPacketSize = 500000; But after 10-15 minutes, I'm seeing the same error again and the stream freezes :( - Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Oct 13 11:32:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 13 Oct 2012 11:32:05 -0700 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: References: Message-ID: <7EC4A79B-5CEF-4752-9B8D-A8F9460551BE@live555.com> > I'm reading from a Sony IP cameras, I'm running: > > ./live/proxyServer/live555ProxyServer -t "rtsp://192.168.88.13/media/video1" > > I'm then trying to read the RTSP with: > > ./live/testProgs/openRTSP 'rtsp://192.168.0.2:554/proxyStream' > > After a while, the stream freezes and I'm getting: RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" This error message (which I presume is being printed by the proxy server, not by "openRTSP") suggests that the TCP connection is 'missing' data, presumably because send() calls by the server (over the TCP connection) have begun. This tells you that the stream's bitrate exceeds the capacity of your TCP connection. There is *nothing* that you can do to overcome this, other than reduce the bitrate of the stream (from your camera). Also, as I said a few days ago (in response to another question): Everyone needs to understand that streaming RTP-over-TCP is something that you should do *only* when you are streaming over a firewall that does not pass UDP packets. You should not think that just because TCP is a 'reliable' transport protocol, that you can use it to ensure 100% delivery of all of the stream data. This may happen if the stream's bitrate is less than the capacity of the TCP connection, but if the stream's bitrate exceeds the capacity of the TCP connection, then you *will* get data loss (and in an inefficient way, because it won't occur on RTP packet boundaries, as it would if you were streaming via RTP/UDP). This is the difference between streaming and 'file/webpage downloading', for example. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Mon Oct 15 07:40:51 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Mon, 15 Oct 2012 14:40:51 +0000 Subject: [Live-devel] Possible to disable use of RTCP? Message-ID: Cisco has confirmed a bug in their VSM-server (v6.3.2) when using RTSP. To get around the bug we've been told to "disabling the use of RTCP when they setup the playback sessions. This is done by only specifying one client port (the RTP port) on the SETUP request. As the sessions are only kept up for 10 seconds, then RTCP is not required. RTCP is only required if the session is going to be longer than 5 minutes." The 10s sessions referred to in the quote is the cycle interval our client uses to switch cameras, i.e. streams are continuously connected and shut down. I haven't found a way to tell liveMedia to not use RTCP, or to change the way the SETUP request is sent. Is it possible? /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Mon Oct 15 13:23:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Oct 2012 13:23:56 -0700 Subject: [Live-devel] Possible to disable use of RTCP? In-Reply-To: References: Message-ID: <7E335801-5144-459D-A8E7-DCA5E087FE2F@live555.com> > Cisco has confirmed a bug in their VSM-server (v6.3.2) when using RTSP. To get around the bug we've been told to "disabling the use of RTCP when they setup the playback sessions. This is done by only specifying one client port (the RTP port) on the SETUP request. As the sessions are only kept up for 10 seconds, then RTCP is not required. RTCP is only required if the session is going to be longer than 5 minutes." > > The 10s sessions referred to in the quote is the cycle interval our client uses to switch cameras, i.e. streams are continuously connected and shut down. I haven't found a way to tell liveMedia to not use RTCP, or to change the way the SETUP request is sent. Is it possible? No. Cisco needs to fix the bug in their server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From smallrui at 126.com Sun Oct 14 05:02:56 2012 From: smallrui at 126.com (Smallrui) Date: Sun, 14 Oct 2012 20:02:56 +0800 (CST) Subject: [Live-devel] help for saving to ts Message-ID: <4c4988a7.be2a.13a5f27d339.Coremail.smallrui@126.com> Hi, plz help me to save streaming to ts. I real need help but i don't know to do it any way. when i found a way from describe "live-devel at lists.live555.com;", the command can be: openRtsp.exe -i rtsp://127.0.0.1:554/test30.mkv > test30.avi It can save the file ok, but no any sound from the saved files. The saved file "test30.avi" only can be play for WMP, the vlc, potplayer cannot be play it yet. When i got a helpfull way from Message-ID: <5FD979BDF2350C4796619C0AC619B38802F113DCAD at FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com He want to save ts to seial of files, I really need this work too. but i cannot understand how to use this code works, i want to recv the stream and muxer it to ts or a seial ts from the different I frames also like him. plz tell me a detail way to use this code or a samples better. thks, here is the test file in archive. brs, rui.sun -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test30.mkv Type: application/octet-stream Size: 1022949 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: savetest30.avi Type: application/octet-stream Size: 1030064 bytes Desc: not available URL: From jshanab at smartwire.com Sun Oct 14 06:24:37 2012 From: jshanab at smartwire.com (Jeff Shanab) Date: Sun, 14 Oct 2012 13:24:37 +0000 Subject: [Live-devel] How to re transmit In-Reply-To: References: Message-ID: <615FD77639372542BF647F5EBAA2DBC22521DC92@IL-BOL-EXCH01.smartwire.com> In the simplest case, H264 defines a protocol that starts with a key frame and has a succession of difference frames that are much smaller. ie the 24KByte key frame has all the information needed to draw the whole frame and the 1Kbyte diff frame has only the changes needed to update the key frame to the new display frame. The first difference frame depends on the key frame and each diff frame depends on the key frame and the changes made by all the proceeding diff frames. One trick would be to have a key frame per second and send and display only keyframes. But since the keyframes are big you can expect at most a 60% reduction on 30fps video. Anything else is transcoding. Decode the video at the source fps and re-encode at the fps you want to display. This can be done in software with libavcodec, but it takes CPU! This also would let you reduce the resolution, sometimes the client is not viewing it at full resolution and that effects bandwidth considerably. ________________________________ From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] on behalf of Tarun Batra [tbatra18 at gmail.com] Sent: Thursday, October 11, 2012 10:20 AM To: live-devel at ns.live555.com Subject: [Live-devel] How to re transmit Hello Sir, I have implemented ?testOnDemandRTSPServer? on my machine which receives h264 transport stream from my streamer application. Is there any way to re transmit this received stream from streamer, to my RTSP clients with different fame rates? As some of my RTSP clients do not have sufficient bandwidth to receive stream with high frame rate. My streamer uses MPEG1or2VideoStreamDiscreteFramer to stream a video from digital camera. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Mon Oct 15 15:34:19 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Mon, 15 Oct 2012 15:34:19 -0700 Subject: [Live-devel] How to re transmit In-Reply-To: <615FD77639372542BF647F5EBAA2DBC22521DC92@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC22521DC92@IL-BOL-EXCH01.smartwire.com> Message-ID: <507C8F6B.5010501@schuckmannacres.com> There are more advanced options, depending on your h.264 encoder. For example the TI h.264 encoder supports a couple of features, Temporal Scalability and Chain Free P Frame encoding. http://processors.wiki.ti.com/index.php/H.264_DM36x_Ver_2.0_Codec#Scalable_video_coding_.E2.80.93_Temporal http://processors.wiki.ti.com/index.php/H.264_DM36x_Ver_2.0_Codec#Chain_Free_P_frame_encoding Both of which allow one to transmit and decode some subset of the encoded bit stream, usually on some even multiple of the key frame frequency. Both of these methods requires you to know or at least discover some pretty detailed information about the bit stream you are retransmitting but it can be done. Matt S. On 10/14/2012 6:24 AM, Jeff Shanab wrote: > In the simplest case, H264 defines a protocol that starts with a key > frame and has a succession of difference frames that are much smaller. > ie the 24KByte key frame has all the information needed to draw the > whole frame and the 1Kbyte diff frame has only the changes needed to > update the key frame to the new display frame. > The first difference frame depends on the key frame and each diff > frame depends on the key frame and the changes made by all the > proceeding diff frames. > > One trick would be to have a key frame per second and send and display > only keyframes. > But since the keyframes are big you can expect at most a 60% reduction > on 30fps video. > > Anything else is transcoding. Decode the video at the source fps and > re-encode at the fps you want to display. > This can be done in software with libavcodec, but it takes CPU! > This also would let you reduce the resolution, sometimes the client is > not viewing it at full resolution and that effects bandwidth considerably. > ------------------------------------------------------------------------ > *From:* live-devel-bounces at ns.live555.com > [live-devel-bounces at ns.live555.com] on behalf of Tarun Batra > [tbatra18 at gmail.com] > *Sent:* Thursday, October 11, 2012 10:20 AM > *To:* live-devel at ns.live555.com > *Subject:* [Live-devel] How to re transmit > > Hello Sir, > > I have implemented "testOnDemandRTSPServer" on my machine which > receives h264 transport stream from my streamer application. > > Is there any way to re transmit this received stream from > streamer, to my RTSP clients with different fame rates? As some of my > RTSP clients do not have sufficient bandwidth to receive stream with > high frame rate. My streamer uses MPEG1or2VideoStreamDiscreteFramer to > stream a video from digital camera. > > > > _______________________________________________ > 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 rglobisch at csir.co.za Mon Oct 15 16:06:25 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Tue, 16 Oct 2012 01:06:25 +0200 Subject: [Live-devel] Re Message-ID: <507CB3110200004D00075874@pta-emo.csir.co.za> Hi Ross, I have some more information, hopefully somewhat helpful in tracking down the problem. I discussed the issue with my colleagues and have now found out that they are also *not* able to receive the stream using the latest version of VLC compiled with live555 2012.10.04. However, using an older build of VLC Android with the live555 2012.10.04 yields *very* good results i.e. a very low failure rate to starting the stream. It even works most of the time over Edge connections. The fixes you've made are most apparent here and have made a *huge* improvement in terms of connectivity. > OK, your log suggests that 'incomplete' data is being received over TCP (by the client), which implies (assuming that your client+server OS's TCP/IP implementation is correct) that some of the server's writes to the TCP socket are failing. The fact that this is happening would seem to indicate it. The thing is though, that a) we have increased the server's TCP send buffers to compensate for a start-up delay and b) we do live rate adaptation according to the bandwidth of the users. c) In the case where we can not adapt the bandwidth to the client's needs, we kick the client from the server. The problem is that the stream never even starts to play. Also, it cannot be a network bandwidth issue since the older version of the app *is* consistently able to stream the media using the same device and same Internet connection. What also doesn't quite add up to me is that VLC reports the Play response as failed: I've attached a recent log I got using the latest VLC live555 combination. Right at the end of the log, one can see that the PLAY request failed, again with the "response buffer truncated" message. This seems to indicate that something has gone wrong during the RTSP exchange. Correct me if I'm wrong, but if it were a TCP send buffer issue, I would first expect the PLAY request to succeed, and then during the PLAY phase first the receiver buffer on the client would fill up, and then the Send buffer on the server and then finally it would fail. I would expect the 200 OK to have been received and processed by the client way before that happens? Further information: this is one of two scenarios that seem to occur on startup. In the other scneario the RTCP handler is called to handle the RTP data until the RTCP buffer fills up (log attached to previous post). Ross, I really don't mean to harp on this issue, but this is currently a show-stopper for us. Any advice would be appreciated. Again, if there is any debug logging you can think of that I can add to the live555 build on Android I'd be glad to add it and report back. Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: live_log.tar.gz Type: application/octet-stream Size: 12954 bytes Desc: not available URL: From finlayson at live555.com Mon Oct 15 19:43:58 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Oct 2012 19:43:58 -0700 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) In-Reply-To: <507CB3110200004D00075874@pta-emo.csir.co.za> References: <507CB3110200004D00075874@pta-emo.csir.co.za> Message-ID: >> OK, your log suggests that 'incomplete' data is being received over TCP (by the client), which implies (assuming that your client+server OS's TCP/IP implementation is correct) that some of the server's writes to the TCP socket are failing. > > > The fact that this is happening would seem to indicate it. The thing is though, that > a) we have increased the server's TCP send buffers to compensate for a start-up delay and > b) we do live rate adaptation according to the bandwidth of the users. > c) In the case where we can not adapt the bandwidth to the client's needs, we kick the client from the server. Nonetheless, the only explanation that I currently have for what you are seeing (i.e., binary data being received by the client over the TCP connection, without proper 'dollar sign' framing for RTP or RTCP packets) is that some of the server's writes to the TCP socket are failing. So why did you not do what I suggested to test for this? To repeat: > You can check this by updating your *server* code as follows: > - add > #define DEBUG_SEND 1 > to "liveMedia/RTPInterface.cpp" > - recompile, then rerun your server. > > If you ever see the error message > sendRTPOverTCP: failed! > then this shows that the server's writes to the TCP socket are eventually overflowing the OS's internal buffer (which should be at least 50 kBytes), which in turn implies that your stream's bitrate is greater than the data capacity of the TCP connection. In this case there is nothing that you can do other than decrease the bitrate of your stream. So please do this and let us know if you see any of these error messages. (If you don't, then I'm at a loss to explain what could be going wrong, unfortunately.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Sun Oct 14 16:40:23 2012 From: hackeron at gmail.com (Roman Gaufman) Date: Mon, 15 Oct 2012 00:40:23 +0100 Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" In-Reply-To: References: <7EC4A79B-5CEF-4752-9B8D-A8F9460551BE@live555.com> Message-ID: Just to follow up, I tried with UDP also and the proxy seems to just freeze after a while and take 100% cpu - I then need to killall -9 live555ProxyServer and restart it to make it receive data again. On 14 October 2012 14:52, Roman Gaufman wrote: > Thank you for a detailed explanation, but I'm still not sure why this > would be happening as the network isn't saturated. The stream is around > 1.5mbps on a 1gbit network with nothing else taking up the bandwidth - it > could be the camera misbehaving I guess? > > My problem however is say the camera is misbehaving or the delivery isn't > 100% briefly for any reason, why would the proxy just freeze and stop > receiving data? - is there any way to get RTSProxy to not just freeze but > rather reset itself or retry or whatever is required to keep receiving the > stream? > > As for UDP, I tried but the stream looks horribly broken with > ffmpeg/opencv - there seems to be some bug processing streams over UDP, I > tried opening 4 different UDP streams from 4 different IP cameras directly > with opencv/ffmpeg (axis ip server, axis camera, sony ip camera and some > chinese IP camera), the stream breaks almost immediately unless I pass > -rtsp_transport tcp > > On 13 Oct 2012, at 19:32, Ross Finlayson wrote: > > I'm reading from a Sony IP cameras, I'm running: > > ./live/proxyServer/live555ProxyServer -t "rtsp:// > 192.168.88.13/media/video1" > > I'm then trying to read the RTSP with: > > ./live/testProgs/openRTSP 'rtsp://192.168.0.2:554/proxyStream' > > After a while, the stream freezes and I'm getting: RTCPInstance error: Hit > limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" > > > This error message (which I presume is being printed by the proxy server, > not by "openRTSP") suggests that the TCP connection is 'missing' data, > presumably because send() calls by the server (over the TCP connection) > have begun. This tells you that the stream's bitrate exceeds the capacity > of your TCP connection. There is *nothing* that you can do to overcome > this, other than reduce the bitrate of the stream (from your camera). > > Also, as I said a few days ago (in response to another question): > Everyone needs to understand that streaming RTP-over-TCP is something that > you should do *only* when you are streaming over a firewall that does not > pass UDP packets. You should not think that just because TCP is a > 'reliable' transport protocol, that you can use it to ensure 100% delivery > of all of the stream data. This may happen if the stream's bitrate is less > than the capacity of the TCP connection, but if the stream's bitrate > exceeds the capacity of the TCP connection, then you *will* get data loss > (and in an inefficient way, because it won't occur on RTP packet > boundaries, as it would if you were streaming via RTP/UDP). This is the > difference between streaming and 'file/webpage downloading', for example. > > 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 Tue Oct 16 13:22:55 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Oct 2012 13:22:55 -0700 Subject: [Live-devel] New "LIVE555 Streaming Media" version, makes servers handle RTP/RTCP-over-TCP send() failures more gracefully Message-ID: After running some tests, I was able to confirm that my suspicions on the cause of the RTP/RTCP-over-TCP issues that Ralf Globisch has been seeing was correct: The problems are caused by some of the server's "send()" calls (on the TCP socket) failing with the 'EAGAIN' error, presumably because the data stream's bit rate has (at least temporarily) exceeded the capacity of the TCP connection. Because transmitting a RTP or RTCP packet over a TCP connection involves four different "send()"s (the '$', the 'stream channel id', packet size, and the packet data), the failure of one - but not all - of these four "send()"s will cause incomplete binary data to appear on the receiver's TCP connection. I have installed a new version (2012.10.16) of the "LIVE555 Streaming Media" software that makes servers handle this a bit more gracefully. If the initial '$' send succeeds, but one of the remaining data send()s (i.e, the 'stream channel id', packet size, or packet data) fails with 'EAGAIN', then we force those send()s to succeed, by temporarily blocking if necessary. (So, Ralf should now upgrade his server(s) to use the latest version of the software.) However, a reminder to everyone, once again, that RTP/RTCP-over-TCP streaming should be used *only* if you are behind a firewall that blocks UDP packets. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Tue Oct 16 13:51:18 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Tue, 16 Oct 2012 22:51:18 +0200 Subject: [Live-devel] New "LIVE555 Streaming Media" version, makes servers handle RTP/RTCP-over-TCP send() failures more gracefully In-Reply-To: References: Message-ID: <507DE4E60200004D00075AB7@pta-emo.csir.co.za> Hi Ross, > I have installed a new version (2012.10.16) of the "LIVE555 Streaming Media" software that makes servers handle this a bit more gracefully. If the initial '$' send succeeds, but one of the remaining data send()s (i.e, the 'stream channel id', packet size, or packet data) fails with 'EAGAIN', then we force those send()s to succeed, by temporarily blocking if necessary. Ok, super! Only saw this post after I sent my previous monster of an email. I'm hoping that I was seeing a symptom of what you describe. On the other hand though there are no failed TCP writes in our server logs (at least in the beginning of streaming), so perhaps there is still another issue. > (So, Ralf should now upgrade his server(s) to use the latest version of the software.) Thanks for your continuous efforts. We will deploy this version shortly and provide you with feedback asap. Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From rglobisch at csir.co.za Tue Oct 16 13:41:25 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Tue, 16 Oct 2012 22:41:25 +0200 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) In-Reply-To: References: <507CB3110200004D00075874@pta-emo.csir.co.za> Message-ID: <507DE2950200004D00075A9F@pta-emo.csir.co.za> Hi Ross, Firstly, I apologise for the missing subject in the previous post. The Novell email software seems to screwing up my outgoing mail every now and then. Apologies in advance if it happens again. > If you ever see the error message > sendRTPOverTCP: failed! > then this shows that the server's writes to the TCP socket are eventually overflowing the OS's internal buffer (which should be at least 50 kBytes), which in turn implies that your stream's bitrate is greater than the data capacity of the TCP connection. In this case there is nothing that you can do other than decrease the bitrate of your stream. I looked through the logs and that message does appear but only sometime later (see mss.log). - Streaming starts around 11:41:28.851871. - The 'sendRTPOverTCP: failed' failed message appears somewhere around 11:42:57.829415 so more than a minute and a half later. - However I would expect the RTSP 200 OK to be processed very much sooner than that and streaming should have started. - Also, like I mentioned we have increased the TCP send buffer sizes so that the stream does not fail on start-up. A colleague of mine was so kind as to run all the software on the local network and send me the logs. I've been staring at them and I think I may have an idea of what's going wrong. Now I don't know the live555 code well enough, but tell me what you think of the following: as far as I understand there are various handlers for the different types of incoming data, one for incoming RTSP messages, and one for RTP/RTCP over TCP starting with a '$'. The $ handler processes the incoming data and then calls either the RTP or the RTCP handler to process the rest of the message. Could it be that once the client starts processing the RTP data i.e. before the 200 OK of the PLAY arrives, that the handler is then set to the $ (RTP/RTCP handler) and that if an RTSP message comes in, even though it gets processed, it's callback/completion handler is not invoked since the socket handling code is now in a "processing $" state? My reasoning is as follows: Looking at the wireshark dump on the client device (client-network.dump): - Network message 73 contains both the interleaved data and the RTSP PLAY response with sequence number 6. Following RTSP message is the $ character and a another 4 characters further there are the characters "apX~" where X=d2. - Now looking at client.live555.log around line 9402 you can see the RTSP response with SN 6 being received by live555. In lines 9411-9427 you can see the "apX~" which matches the wireshark log. The '$' header never appeared the additional output logging since I assume that it got handled somewhere else in the code explaining why I couldn't find the $ sign previously. The data continuously being printed in client.live555.log is the content of fResponseBuffer from RTSPClient.cpp. The fact that in line 9411 the 200 OK has been removed from the buffer would indicate that live555 has processed that message. Therefore the VLC code should also have processed the 200 OK around this point in time, but this never happens (see client.VLC.log). Typically at some point VLC reports: 'E/VLC (18053): [0x2dbda8]: live555 demux RTSP PLAY failed RTSP response was truncated. Increase "RTSPClient::responseBufferSize"' - At line 17730 the ' RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize"' message starts flooding the log file which eventually hangs VLC. This all seems to indicate that the live555 is still actively processing incoming data: I think that the main issue is that the PLAY callback never returns, which seems to indicate that if the live555 code has started processing RTP/RTCP over TCP data, the 200 OK is ignored somehow. Any thoughts on this? Please let me know If you want me to try out any fixes, add logging, etc. Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logs.tar.gz Type: application/octet-stream Size: 201925 bytes Desc: not available URL: From finlayson at live555.com Tue Oct 16 14:46:26 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Oct 2012 14:46:26 -0700 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) In-Reply-To: <507DE2950200004D00075A9F@pta-emo.csir.co.za> References: <507CB3110200004D00075874@pta-emo.csir.co.za> <507DE2950200004D00075A9F@pta-emo.csir.co.za> Message-ID: <760AB643-ABC2-4B84-AF39-FE8240ACB340@live555.com> > Could it be that once the client starts processing the RTP data i.e. before the 200 OK of the PLAY arrives, that the handler is then set to the $ (RTP/RTCP handler) and that > if an RTSP message comes in, even though it gets processed, it's callback/completion handler is not invoked since the socket handling code is now in a "processing $" state? No, the RTP/RTSP-over-TCP receiving code (in "liveMedia/RTPInterface.cpp") is set up to properly handle either a RTP or RTCP packet (which is framed beginning with a '$' etc.), or a RTSP request or response. If the RTSP request or response handling code is ever called with binary data (i.e., from a RTP or RTCP packet) by mistake, then it must be because it appeared in the stream without proper '$' framing. But (with our server) the only way that that can happen is if some of the server's "send()"s have failed. With the latest software release, however, a server streaming over an overloaded TCP connection should no longer ever send only a partially-formed '$'-framed RTP or RTCP packet. So if you still see problems even with the latest version of the software (for both the server and client), then you're going to have to track this down yourself. (Please don't bother sending 'wireshark' logs; I never look at those.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aashish.Kaushik at hcl.com Wed Oct 17 04:53:49 2012 From: Aashish.Kaushik at hcl.com (Aashish Kaushik) Date: Wed, 17 Oct 2012 17:23:49 +0530 Subject: [Live-devel] ProxyServer: Not getting stream after proxied server disconnects and connects Message-ID: <8706360947A56E45B1418C635D36596402454B861AE7@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> Hi Ross, I am using Live555ProxyServer to proxy a stream from a camera. Proxy server establishes the session with the camera and I am able to get the stream from the proxy. However, in case camera gets disconnected and then connects again. Now if I try to get stream from the proxy using a RTSP client, proxy sends a SETUP command to camera with the same session id that was being used before camera got disconnected. Now camera responds with "454 Session Not Found", so I am not able to get the stream from the proxy. Once the camera is disconnected shouldn't proxy TEARDOWN the established session? Also, after the camera gets connected again, should not proxy try to establish a new RTSP session by sending a SETUP without a Session Id? I tried with a new version of live555Proxy as well, it sends a DESCRIBE request, however, SETUP command after DESCRIBE is having same Session ID as was in previous established session. Hence same "454 Session Not Found" response. Please suggest in this regard. Thanks & Regards, Aashish Kaushik HCL Technologies Ltd. www.hcltech.com 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 Oct 17 07:55:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Oct 2012 07:55:20 -0700 Subject: [Live-devel] ProxyServer: Not getting stream after proxied server disconnects and connects In-Reply-To: <8706360947A56E45B1418C635D36596402454B861AE7@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> References: <8706360947A56E45B1418C635D36596402454B861AE7@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> Message-ID: > I tried with a new version of live555Proxy as well You should have tried with a new version *only*, because (as you know) the latest version of the software is the only version that we support. > , it sends a DESCRIBE request, however, SETUP command after DESCRIBE is having same Session ID as was in previous established session. Hence same ?454 Session Not Found? response. Thanks for the report. I have now installed a new version (2012.10.17) of the "LIVE555 Streaming Media" software that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Wed Oct 17 10:56:53 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Wed, 17 Oct 2012 10:56:53 -0700 Subject: [Live-devel] RTSP_BUFFER_SIZE=10000 not big enough for larger SDP Message-ID: <507EF165.4090507@schuckmannacres.com> Hi Ross, We are putting a rather large custom calibration structure (xml text) in the SDP for our media sessions and we ran into a limit on the server side. In the RTSPServer code the fResponseBuffer and fRequestBuffer are both limited by the #define of RTSP_BUFFER_SIZE which is set to 10000. For now I've just changed the code to a larger size, but I'm wondering if there is something else I should be doing? I figure at a minimum it should be changed to allow one to change this value via a -D option in the makefile. Thanks, Matt S. From rglobisch at csir.co.za Wed Oct 17 17:36:42 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Thu, 18 Oct 2012 02:36:42 +0200 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) Message-ID: <507F6B3A0200004D00075D59@pta-emo.csir.co.za> Hi Ross, > So if you still see problems even with the latest version of the software (for both the server and client), then you're going to have to track this down yourself. (Please don't bother sending 'wireshark' logs; I never look at those.) After upgrading the server, the issue persisted as I suspected. I have managed to track it down though, please review the attached patch. I'm not sure if there are any (unintended) side-effects to my modifications. > cd live.2012.10.17/ > patch -p1 <./live555_2.patch Brief explanation: once the $ sign is parsed with no handler for the channel, the remaining RTP data was not being read from the socket as "data" causing the RTSP response which follows later in the stream to never get parsed, and as a result the PLAY callback was never invoked. I've tried patching live2012.10.17 and then rebuilding VLC android to test the fix. In the few tests I ran RTSP streams over TCP were working again. Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From rglobisch at csir.co.za Wed Oct 17 17:41:19 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Thu, 18 Oct 2012 02:41:19 +0200 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) In-Reply-To: <760AB643-ABC2-4B84-AF39-FE8240ACB340@live555.com> References: <507CB3110200004D00075874@pta-emo.csir.co.za> <507DE2950200004D00075A9F@pta-emo.csir.co.za> <760AB643-ABC2-4B84-AF39-FE8240ACB340@live555.com> Message-ID: <507F6C4F0200004D00075D62@pta-emo.csir.co.za> >>> Ross Finlayson 16/10/12 11:50 PM >>> Apologies, the buggy mail software seems to have dropped the attached patch, or at least I can't see it on the mailing list. Attempt #2. Regards,Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: live555_2.patch Type: application/octet-stream Size: 2562 bytes Desc: not available URL: From finlayson at live555.com Wed Oct 17 17:44:17 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Oct 2012 17:44:17 -0700 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) In-Reply-To: <507F6B3A0200004D00075D59@pta-emo.csir.co.za> References: <507F6B3A0200004D00075D59@pta-emo.csir.co.za> Message-ID: Oops, you forgot to attach your patch. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 17 18:06:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Oct 2012 18:06:33 -0700 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) In-Reply-To: <507F6C4F0200004D00075D62@pta-emo.csir.co.za> References: <507CB3110200004D00075874@pta-emo.csir.co.za> <507DE2950200004D00075A9F@pta-emo.csir.co.za> <760AB643-ABC2-4B84-AF39-FE8240ACB340@live555.com> <507F6C4F0200004D00075D62@pta-emo.csir.co.za> Message-ID: <9651EA5C-E48A-42CA-944C-2ADB99104A5E@live555.com> Ralf, Thanks for the note. Your patch looks like a good idea; it will likely be incorporated into the next release of the software. However, although your patch is a good idea (basically, a 'sanity check' for the case when a '$'-framed packet is received without an appropriate handler for the stream channel), I'm still puzzled by why it happened to be necessary. In our current "RTSPClient" implementation, the stream channel ids (for RTP and RTCP) are 'registered' just after the "SETUP" response has been received (and thus before "PLAY" is sent). Note the calls to "setStreamSocket() in "RTSPClient.cpp", lines 1027 and 1032. Therefore, I don't see how a RTP or RTCP packet being sent by the server after it receives the "PLAY" request (even if it's sent before the "PLAY" response) could cause this situation (no appropriate handler) to occur? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 18 01:06:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Oct 2012 01:06:56 -0700 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) In-Reply-To: <507F6C4F0200004D00075D62@pta-emo.csir.co.za> References: <507CB3110200004D00075874@pta-emo.csir.co.za> <507DE2950200004D00075A9F@pta-emo.csir.co.za> <760AB643-ABC2-4B84-AF39-FE8240ACB340@live555.com> <507F6C4F0200004D00075D62@pta-emo.csir.co.za> Message-ID: <915450A8-DA4C-4FC4-88C8-175CDB21CDC2@live555.com> Ralf, I've now installed a new version (2012.10.18) of the "LIVE555 Streaming Media" code that incorporates (the equivalent of) your proposed fix. Please test it (in your VLC client) to make sure that it works OK for you. BTW, I now understand why you saw this situation occur, but I never did. It's because I used "openRTSP" as my client (when testing), and "openRTSP" starts reading from its input source(s) after receiving the "SETUP" response, before sending "PLAY". Because it's the act of reading from an input source that causes the 'read handler' function to get registered (in the "RTPInterface" code), I never encountered your situation. You, however, are using VLC for your client, and VLC apparently does not start reading from its input source(s) until sometime after sending the RTSP "PLAY" command. This explains why it could sometimes receive an embedded RTP or RTCP packet before a 'read handler' had been registered. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 18 01:24:13 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Oct 2012 01:24:13 -0700 Subject: [Live-devel] RTSP_BUFFER_SIZE=10000 not big enough for larger SDP In-Reply-To: <507EF165.4090507@schuckmannacres.com> References: <507EF165.4090507@schuckmannacres.com> Message-ID: <3AFFA621-1290-49B9-82DE-179615F3A418@live555.com> > For now I've just changed the code to a larger size, but I'm wondering if there is something else I should be doing? I figure at a minimum it should be changed to allow one to change this value via a -D option in the makefile. OK, in the next version of the code, I'll enclose the definition in #ifndef RTSP_BUFFER_SIZE #endif to allow you to redefine it on the compile line, if desired. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Thu Oct 18 05:44:10 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Thu, 18 Oct 2012 14:44:10 +0200 Subject: [Live-devel] Re (your issues with RTP-over-TCP streaming) In-Reply-To: <915450A8-DA4C-4FC4-88C8-175CDB21CDC2@live555.com> References: <507CB3110200004D00075874@pta-emo.csir.co.za> <507DE2950200004D00075A9F@pta-emo.csir.co.za> <760AB643-ABC2-4B84-AF39-FE8240ACB340@live555.com> <507F6C4F0200004D00075D62@pta-emo.csir.co.za> <915450A8-DA4C-4FC4-88C8-175CDB21CDC2@live555.com> Message-ID: <508015BA0200004D00075E8F@pta-emo.csir.co.za> > I've now installed a new version (2012.10.18) of the "LIVE555 Streaming Media" code that incorporates (the equivalent of) your proposed fix. Please test it (in your > VLC client) to make sure that it works OK for you. Thanks Ross, much appreciated. I will test it asap. > You, however, are using VLC for your client, and VLC apparently does not start reading from its input source(s) until sometime after sending the RTSP "PLAY" command. This explains why it could sometimes receive an embedded RTP or RTCP packet before a 'read handler' had been registered. Ok, thanks for the information. I was going to add some more debugging tonight to see why there were no handlers. Thanks for saving me the effort :-) -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From Bruno.Marchand at averna.com Thu Oct 18 07:45:06 2012 From: Bruno.Marchand at averna.com (Bruno Marchand) Date: Thu, 18 Oct 2012 10:45:06 -0400 Subject: [Live-devel] PresentationTimeSessionNormalizer Message-ID: Hi Ross, Could it be possible to make the two classes "PresentationTimeSessionNormalizer" and "PresentationTimeSubsessionNormalizer" visible to the library users? At this time, they are both hidden in the "ProxyServerMediaSession" cpp. They work fine when using the "ProxyServerMediaSession" but my use case requires I implement my own "OnDemandServerMediaSubsession" and keep control over the RTSP client session. Because I retransmit the RTP data, I also need to use the normalizer components to avoid the RTCP timestamp synchronization issue you already know. Thanks, Bruno Marchand -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aashish.Kaushik at hcl.com Thu Oct 18 04:13:16 2012 From: Aashish.Kaushik at hcl.com (Aashish Kaushik) Date: Thu, 18 Oct 2012 16:43:16 +0530 Subject: [Live-devel] ProxyServer: Not getting stream after proxied server disconnects and connects In-Reply-To: References: <8706360947A56E45B1418C635D36596402454B861AE7@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> Message-ID: <8706360947A56E45B1418C635D36596402454B861F41@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> Hi Ross, Thanks for the response. I tried with the latest version (2012.10.17). Initial stream is working fine. However once camera gets disconnected and reconnected then if I try to stream through proxy, only audio stream is playing and video stream is not playing. I am using VLC as client. I checked the ethereal logs between proxy and the Camera. Now after camera gets re-connected Proxy sends DESCRIBE, then SETUP (for trackID=0), then SETUP (for trackID=1) and again sends SETUP(for trackID=0) for which camera responds with "461 Unsupported Transport". Proxy need not send SETUP again (for trackID=0). Attached are the ethereal logs for the same. Also, when I checked the codec page in VLC for this stream (with Audio only playing) coming from Proxy it is showing so many stream as shown in below image: [cid:image003.jpg at 01CDAD4F.AC1680F0] Thanks & Regards, Aashish Kaushik HCL Technologies Ltd. www.hcltech.com www.hcl.com From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, October 17, 2012 8:25 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] ProxyServer: Not getting stream after proxied server disconnects and connects I tried with a new version of live555Proxy as well You should have tried with a new version *only*, because (as you know) the latest version of the software is the only version that we support. , it sends a DESCRIBE request, however, SETUP command after DESCRIBE is having same Session ID as was in previous established session. Hence same "454 Session Not Found" response. Thanks for the report. I have now installed a new version (2012.10.17) of the "LIVE555 Streaming Media" software that fixes this. 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: image003.jpg Type: image/jpeg Size: 29502 bytes Desc: image003.jpg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Proxy_Camera_logs.txt URL: -------------- next part -------------- ::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 Thu Oct 18 17:27:41 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Oct 2012 17:27:41 -0700 Subject: [Live-devel] ProxyServer: Not getting stream after proxied server disconnects and connects In-Reply-To: <8706360947A56E45B1418C635D36596402454B861F41@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> References: <8706360947A56E45B1418C635D36596402454B861AE7@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> <8706360947A56E45B1418C635D36596402454B861F41@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> Message-ID: <797D8EB4-B276-42B7-9A0F-16FA936DD91F@live555.com> > I checked the ethereal logs between proxy and the Camera. Now after camera gets re-connected Proxy sends DESCRIBE, then SETUP (for trackID=0), then SETUP (for trackID=1) and again sends SETUP(for trackID=0) for which camera responds with ?461 Unsupported Transport?. Proxy need not send SETUP again (for trackID=0). Thanks for the note. I've just installed a new version (2012.10.19) that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 18 17:29:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Oct 2012 17:29:23 -0700 Subject: [Live-devel] PresentationTimeSessionNormalizer In-Reply-To: References: Message-ID: > Could it be possible to make the two classes ?PresentationTimeSessionNormalizer? and ?PresentationTimeSubsessionNormalizer? visible to the library users? Grumble. I wasn't planning to, because those classes were intended to be used only by our proxy server implementation. But I've made those two class definitions visible in the latest release (2012.10.19). (Don't complain, though, if they don't do what you want them to :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.delucis at multisentry.com Fri Oct 19 02:19:13 2012 From: m.delucis at multisentry.com (Mauro Delucis) Date: Fri, 19 Oct 2012 11:19:13 +0200 Subject: [Live-devel] No RTSP session is currently in progress Message-ID: <50811B11.8000901@multisentry.com> Hello! I have a problemwith live555, I hope this is the right mailing list. My application acquires rtsp streams from an IP camera. Until a few days ago the application was working properly, then I updated the LIVE555 libraries and the program started to report the message: "No RTSP session is currently in progress" What could be causing this? I compiled the libraries with the -DRTSPCLIENT_SYNCHRONOUS_INTERFACE = 1 Thank you! -- Mauro Delucis Responsabile R & D, analista programmatore Multisentry Solutions S.r.l. Via G. De Sonnaz, 27 - 18100 Imperia (IM) tel +39 0183 73.81.93 fax +39 0183 73.04.01 From finlayson at live555.com Fri Oct 19 05:47:26 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Oct 2012 05:47:26 -0700 Subject: [Live-devel] No RTSP session is currently in progress In-Reply-To: <50811B11.8000901@multisentry.com> References: <50811B11.8000901@multisentry.com> Message-ID: > My application acquires rtsp streams from an IP camera. Until a few days ago the application was working properly, then I updated the LIVE555 libraries and the program started to report the message: "No RTSP session is currently in progress" > > What could be causing this? Because the error occurs with your custom application, it's difficult to say for sure, but most likely it's because your client is sending an operation (such as "PLAY") on a session, without having first sent a "SETUP". (I'm not sure why your application worked before, though.) To find out for sure what's going on, please change your application to pass 1 as the "verbosityLevel" parameter to the call to "RTSPClient::createNew()", rerun your application, and send us the diagnostic output (from 'stderr'). > I compiled the libraries with the -DRTSPCLIENT_SYNCHRONOUS_INTERFACE = 1 Note that the synchronous "RTSPClient" interface is now deprecated, and may be removed sometime in the future. You should consider upgrading your application to use the asynchronous interface (I suggest using the "testRTSPClient" code as a model). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.meding at ids-imaging.de Fri Oct 19 05:54:41 2012 From: m.meding at ids-imaging.de (Meding, Matthias) Date: Fri, 19 Oct 2012 14:54:41 +0200 Subject: [Live-devel] Authorization question Message-ID: <4CB3F3483954BD4ABD0B4DBB35C7E33802D45BCF@exchsrv.idszentral.local> Hello Ross, in the method "RTSPServer::RTSPClientConnection::authenticationOK" is only checked whether the "fAuthDB" is NULL. Would it not make sense to check if the "AuthDB" is empty ("fAuthDB->IsEmpty()")? Greetings Matthias Meding -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 19 06:19:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Oct 2012 06:19:47 -0700 Subject: [Live-devel] Authorization question In-Reply-To: <4CB3F3483954BD4ABD0B4DBB35C7E33802D45BCF@exchsrv.idszentral.local> References: <4CB3F3483954BD4ABD0B4DBB35C7E33802D45BCF@exchsrv.idszentral.local> Message-ID: > in the method "RTSPServer::RTSPClientConnection::authenticationOK" is only checked whether the "fAuthDB" is NULL. Would it not make sense to check if the "AuthDB" is empty ("fAuthDB->IsEmpty()")? No, no special code is needed for this case. If the authentication database exists, but is empty (i.e., no , pairs have yet been entered into it), then all commands will fail with "401 Unauthorized". Which is as it should be. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.delucis at multisentry.com Fri Oct 19 07:17:50 2012 From: m.delucis at multisentry.com (Mauro Delucis) Date: Fri, 19 Oct 2012 16:17:50 +0200 Subject: [Live-devel] No RTSP session is currently in progress In-Reply-To: References: <50811B11.8000901@multisentry.com> Message-ID: <5081610E.8020305@multisentry.com> Hello Ross, I can't use the asynchronous interface right now because I have no time to develop the changes... unfortunately! Customers are always in a hurry! I temporarily solved my problem by calling the old setupMediaSubsession instead of sendSetupCommand. I know that is not very nice. Mauro. Il 19/10/2012 14:47, Ross Finlayson ha scritto: >> My application acquires rtsp streams from an IP camera. Until a few >> days ago the application was working properly, then I updated the >> LIVE555 libraries and the program started to report the message: "No >> RTSP session is currently in progress" >> >> What could be causing this? > > Because the error occurs with your custom application, it's difficult > to say for sure, but most likely it's because your client is sending > an operation (such as "PLAY") on a session, without having first sent > a "SETUP". (I'm not sure why your application worked before, though.) > > To find out for sure what's going on, please change your application > to pass 1 as the "verbosityLevel" parameter to the call to > "RTSPClient::createNew()", rerun your application, and send us the > diagnostic output (from 'stderr'). > > >> I compiled the libraries with the -DRTSPCLIENT_SYNCHRONOUS_INTERFACE = 1 > > Note that the synchronous "RTSPClient" interface is now deprecated, > and may be removed sometime in the future. You should consider > upgrading your application to use the asynchronous interface (I > suggest using the "testRTSPClient" code as a model). > > 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 -- Mauro Delucis Responsabile R & D, analista programmatore Multisentry Solutions S.r.l. Via G. De Sonnaz, 27 - 18100 Imperia (IM) tel +39 0183 73.81.93 fax +39 0183 73.04.01 AVVISO di RISERVATEZZA Questo messaggio di posta elettronica contiene informazioni rivolte esclusivamente al destinatario sopra indicato. E' vietato l'uso, la diffusione, distribuzione o riproduzione da parte di ogni altra persona, salvo autorizzazione del mittente. Nel caso aveste ricevuto questo messaggio di posta elettronica per errore, siete pregati di segnalarlo immediatamente al mittente e distruggere quanto ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione del divieto di prendere cognizione della corrispondenza tra altri soggetti, salvo pi? grave illecito, ed espone il responsabile alle relative conseguenze. This e-mail contains information that are intended solely for the above mentioned addressee. Any use, disclosure, dissemination or copying of the information in this e-mail by any other party is strictly forbidden, unless authorised by the sender. If you have received this e-mail in error, please notify the sender immediately and destroy it (including any attachments), without copying it. Whatsoever unauthorised use of the content of this e-mail is an infringement of the prohibition to take cognizance of the correspondence among other entities, unless a more serious violation of the law occurred, and exposes the responsible to the consequences thereof. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 19 12:04:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Oct 2012 12:04:03 -0700 Subject: [Live-devel] No RTSP session is currently in progress In-Reply-To: <5081610E.8020305@multisentry.com> References: <50811B11.8000901@multisentry.com> <5081610E.8020305@multisentry.com> Message-ID: <2D216614-7D8E-4701-99E2-82BE22317885@live555.com> > I temporarily solved my problem by calling the old setupMediaSubsession instead of sendSetupCommand. > > I know that is not very nice. No, it's exactly right. If you use the old synchronous RTSPClient interface, then *all* of your "RTSPClient" function calls should be from that old interface. Your problem was apparently that you called "sendSetupCommand()" - a function from the new asynchronous interface - but then called a function to send a RTSP "PLAY" before you had handled a response to the RTSP "SETUP" command. Functions from the new asynchronous interface (except, perhaps, for the initial "sendDescribeCommand()" call) need to be called from within event handlers - i.e., after you've already called "doEventLoop()" to enter the application's event loop. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erduhai at qq.com Fri Oct 19 04:09:07 2012 From: erduhai at qq.com (=?gb18030?B?0fS6o7z+?=) Date: Fri, 19 Oct 2012 19:09:07 +0800 Subject: [Live-devel] How to set fPresentationTime in my framedsource Message-ID: Hi Ross, I add a class H264VideoUDPSource to live555 for my IP Camera project. when played by VLC, its picture does not updated,and i can see a lot of picture drop in VLC information. code is like this:class H264VideoUDPSource: public FramedSource void H264VideoUDPSource::doGetNextFrame() { //fill a h264 frame ... //set timestamp, since it is live source, i guess it can be wall clock time? gettimeofday(&fPresentationTime, NULL); //live source don't need set duration //fDurationInMicroseconds nextTask() = envir().taskScheduler().scheduleDelayedTask(0, (TaskFunc*)FramedSource::afterGetting, this); } //------ I also try another way, when played in VLC, video is ok, but it get pause every few seconds. // Set the 'presentation time': if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0) gettimeofday(&fPresentationTime, NULL); else { // Increment by the play time of the previous frame: unsigned uSeconds = fPresentationTime.tv_usec + 1000000/25; //25fps, the real frame speed from camera is about 5~7frames/s fPresentationTime.tv_sec += uSeconds/1000000; fPresentationTime.tv_usec = uSeconds%1000000; } Thank you! jerry yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 19 18:15:35 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Oct 2012 18:15:35 -0700 Subject: [Live-devel] How to set fPresentationTime in my framedsource In-Reply-To: References: Message-ID: Because you are streaming from a live source, your first method of setting "fPresentationTime" - i.e., just by calling "gettimeofday()" - is best. However, I doubt that this is the cause of the problems that you are seeing when you are trying to view your stream using VLC. You haven't said anything else about the rest of your application, but you should make sure that your "H264VideoUDPSource" feeds its H.264 NAL units - *without* any preceding 4-byte 'start codes' - to a "H264VideoStreamDiscreteFramer" (*not* a "H264VideoStreamFramer"), and from this into a "H264VideoRTPSink". Also, if you are having problems viewing your stream using VLC, I suggest that you first try using "openRTSP" to receive your stream, and record it into a file. Rename the resulting file to have a ".h264" filename suffix, and see if you can play this file using VLC. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruno.Marchand at averna.com Sun Oct 21 03:59:15 2012 From: Bruno.Marchand at averna.com (Bruno Marchand) Date: Sun, 21 Oct 2012 06:59:15 -0400 Subject: [Live-devel] PresentationTimeSessionNormalizer In-Reply-To: References: Message-ID: Grumble. I wasn't planning to, because those classes were intended to be used only by our proxy server implementation. But I've made those two class definitions visible in the latest release (2012.10.19). (Don't complain, though, if they don't do what you want them to :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ Thank you for making the interface available. It will ease my job when I'll upgrade to a new version. Regards, Bruno Marchand -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruno.Marchand at averna.com Sun Oct 21 04:28:20 2012 From: Bruno.Marchand at averna.com (Bruno Marchand) Date: Sun, 21 Oct 2012 07:28:20 -0400 Subject: [Live-devel] PresentationTimeSessionNormalizer, again! Message-ID: Hi Ross, I found a small bug in the "PresentationTimeSessionNormalizer" class. It can be reproduced with the live555ProxyServer so it is unrelated to the fact I'm using it in my application and I'm not complaining! ;) The symptoms occurs when I use a multi subsession source such as my camera which stream H264 and AAC. The proxy server do RTCP synchronize both of the streams with the camera. When a client like testRTSPclient connects to the proxy server, only one stream will RTCP synchronize, usually the h264. The fix is just a matter of moving a curly brace. The "if" where the master normalizer is set also controls the part where the RTPsinks get RTCP enabled so only the "master stream" emit RTCP reports. I included a patch which resolves the bug. I hope this can be of some help, Bruno Marchand -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ProxyServerMediaSession.patch Type: application/octet-stream Size: 1511 bytes Desc: ProxyServerMediaSession.patch URL: From steven at avd.com.au Sun Oct 21 03:57:06 2012 From: steven at avd.com.au (Steven Yang) Date: Sun, 21 Oct 2012 21:57:06 +1100 Subject: [Live-devel] Http/Mjpeg to Rtsp/Mpeg4 video transcoding latency Message-ID: Hi Im currently working on a OSX project to transcode Mjpeg from IP camera to RTSP mpeg4 with libavcodec The Stream from camera is 1280x960 at 4fps. I implemented the subclass of FrameSource and use MPEG4DescreteVideoFramer and feed FramerSource Mjpeg streaming and encoding is done in separate thread and the output AVPackets are stored in a que FramedSource::doGetNextFrame check if there is any packet in the que and deliver it, otherwise schedule a delayed call on FramedSource::doGetNextFrameStatic to do frame checking again. the program works but got serious latency problem (3~12 seconds ), seen from FFplay it complains 100+ RTP packet lost. 1.For comparision I tried ffserver+ffmpeg the latency is ~1seconds. FFplay complains RTP lost too but much less 1~2 packet lost. 2. In my implementation, I can confirm the mjpeg receiving/decoding and mpeg4 encoding too less than 100ms for each frame. 3. I notice doNextFrame often couldn't get data and issue a delayed retry, the problem is it is called repeatedly more than 20 times per seconds since I use 0ms delay, wondering this could be the problem? I did tried 100ms but seems doesn't really help... Is it possible doGetNextFrame is called too frequently? Is there any other reason can cause the problem? PS: I'm running EVERYTHING on a MacBook Pro with 2.4Ghz CPU and 8GB ram. Thanks! Regards Steven Sent from my iPhone From finlayson at live555.com Sun Oct 21 05:35:41 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Oct 2012 05:35:41 -0700 Subject: [Live-devel] PresentationTimeSessionNormalizer, again! In-Reply-To: References: Message-ID: Thanks. I've just installed a new version of the code (2012.10.21) that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Oct 21 05:44:46 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Oct 2012 05:44:46 -0700 Subject: [Live-devel] Http/Mjpeg to Rtsp/Mpeg4 video transcoding latency In-Reply-To: References: Message-ID: <998868C6-62AC-4EC4-8EC7-91F2D5E10C39@live555.com> > Mjpeg streaming and encoding is done in separate thread and the output AVPackets are stored in a que > > FramedSource::doGetNextFrame check if there is any packet in the que and deliver it, otherwise schedule a delayed call on FramedSource::doGetNextFrameStatic to do frame checking again. This is inefficient. A much better solution is to use 'event triggers', and whenever a new encoded frame has been completed, have the encoding thread call "triggerEvent()" (the only LIVE555 function that can be called from a non-LIVE555 thread) to tell the LIVE555 thread that a new frame is available for delivery. For an illustration of how to do this, see the model code in "liveMedia/DeviceSource.cpp". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 22 07:03:48 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Oct 2012 07:03:48 -0700 Subject: [Live-devel] report a bug of openRTSP In-Reply-To: References: <7957C35F-6D0D-4801-A5EC-68140A418A5F@live555.com> Message-ID: <9F2EE2AA-11D3-44EF-99FE-8721B7FBC655@live555.com> > Thanks for your advice of redirecting stdout to a file, it works, and I find the issue that dumped avi file cannot play in windows media player, that's because the avi file has no index in the end. Now I make some changes by add the index to the file after written movi data. > i enclose the two changed files, but the changed code maybe uglily written, hope it be changed gracefully. FYI, the latest version (2012.10.22) of the "LIVE555 Streaming Media" code updates the "AVIFileSink" implementation to add an index at the end of each AVI file, as you suggested. However, I'm not sure if the implementation is correct, because when I tried running "openRTSP" to record a AVI file, and then used VLC to try playing the file, VLC still complained about the AVI file index being "broken or missing". So, please check the code, and let me know if there are any problems. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Mon Oct 22 23:52:20 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Tue, 23 Oct 2012 14:52:20 +0800 Subject: [Live-devel] regarding sps/pps in live555 Message-ID: <000001cdb0ea$f4a25e90$dde71bb0$@126.com> Hi, I used to live555 send h264 stream. And I use H264VideoRTPSink::createNew(envir(),rtpGroupsock,rtpPayloadTypeIfDynamic) to create rtp sink. In the createnew function, I don?t deliver sps/pps to live555. So I guess live555 would parse the sps/pps from the h264 stream, but I don? t know whether live555 stores these value. Currently if I use VLC to access the rtsp server, in the first time, it would play correctly. And if I stop it , then access it again, it would also shows that ?waiting for sps/pps?. So should I deliver the sps/pps to live555 explicitly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 23 00:17:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Oct 2012 00:17:03 -0700 Subject: [Live-devel] regarding sps/pps in live555 In-Reply-To: <000001cdb0ea$f4a25e90$dde71bb0$@126.com> References: <000001cdb0ea$f4a25e90$dde71bb0$@126.com> Message-ID: > So I guess live555 would parse the sps/pps from the h264 stream, but I don?t know whether live555 stores these value. Yes it does. The "H264VideoStreamFramer" (or "H264VideoStreamDiscreteFramer") object - which precedes the "H264VideoRTPSink" object in the data stream - will store copies of the SPS and PPS NAL units when it sees them. Those will get encoded and included in the stream's SDP description (in the response to each client's RTSP "DESCRIBE" command). > Currently if I use VLC to access the rtsp server, in the first time, it would play correctly. And if I stop it , then access it again, it would also shows that ?waiting for sps/pps?. This is apparently a VLC problem, which we can't help you with (because VLC is not our software). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eran.ma at vglnt.com Wed Oct 24 02:39:54 2012 From: eran.ma at vglnt.com (Eran) Date: Wed, 24 Oct 2012 09:39:54 +0000 (UTC) Subject: [Live-devel] Streaming h264 MPEG-2 TS References: Message-ID: Oshi Keren-Zur writes: > > > Hi,We are developing a linux based embedded device which functions as a streaming server.The device has a video encoder which produces h264 MPEG-4 Elementary Stream, Audio encoder, and closed caption source.Our project started off with the requirement to stream the Video by RTP. We used liveMedia for this.As the project evolved additional requirements/limitations were added:1. Offline streaming of previously captured data with trick-play2. The Streaming client can only play MPEG-2 ts.After some research regarding extending our use of liveMedia to satisfy these requirements,We reached the conclusion that using liveMedia as it is currently implemented will be difficult since1. Multiplexing of h.264, audio and closed captions to an MPEG-2 ts is > not supported2. Indexing of h264 video for trick play is not supported.Is our conclusion correct? If not, we would appreciate some guidance on how to solve the above problems.Otherwise, is there some other tool/library that can perform this?Thanks,Oshi > > > _______________________________________________ > live-devel mailing list > live-devel at ... > http://lists.live555.com/mailman/listinfo/live-devel > Hi. We're also developing a linux based embedded device (based on TI DM368) which functions as a streaming server, and has a video encoder which produces h264 MPEG-4 Elementary Stream (it gives me pointers to encoded h264 frames). We also use RTP right now, and we also have a new requirement to use MPEG-2 ts instead. I've noticed that liveMedia can produce an MPEG-2 ts stream from an h264 file as a source, but I haven't managed to use it with our h264 stream produced from the encoder in "real time" as a source. Have you managed to get it done? Can you please share how? Thanks! From finlayson at live555.com Wed Oct 24 06:14:58 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Oct 2012 06:14:58 -0700 Subject: [Live-devel] Streaming h264 MPEG-2 TS In-Reply-To: References: Message-ID: <8C80217E-093E-4516-93F0-ED64A5BDE926@live555.com> I found your message rather disjointed and confusing, but I hope the following answers your question(s): - Our RTSP server implementation *does* support 'trick play' operation on MPEG Transport Stream files (but not 'live' MPEG Transport Stream data). These Transport Stream files can contain MPEG-1, MPEG-2, or H.264 Video (plus audio, text, etc. tracks). An 'index file' must be created for each Transport Stream file (for 'trick play' operations to work). For more information, see http://www.live555.com/liveMedia/transport-stream-trick-play.html - Our software *can* be used to create a MPEG Transport Stream from a H.264 video input (and at least some types of MPEG audio input), using the "MPEG2TransportStreamFromESSource" class. Note, in particular, the "testH264VideoToTransportStream" demo application (in the "testProgs" directory) that shows how to generate a MPEG Transport Stream file from a H.264 video Elementary Stream file. - I'm not sure how you would add 'closed caption' subtitles to a MPEG Transport Stream, but you may be able to do this by subclassing "MPEG2TransportStreamFromESSource", and have your subclass define a new "addNewTextSource()" member function that calls the "addNewInputSource()" member function (which is "protected:" as of the latest release of the software). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eran.ma at vglnt.com Wed Oct 24 07:32:38 2012 From: eran.ma at vglnt.com (Eran) Date: Wed, 24 Oct 2012 14:32:38 +0000 (UTC) Subject: [Live-devel] Streaming h264 MPEG-2 TS References: <8C80217E-093E-4516-93F0-ED64A5BDE926@live555.com> Message-ID: Actually I don't need trick play or closed captions. I only need to use Mpeg-2 Transport Stream to stream my h264 video that is encoded in real time, and "testH264VideoToTransportStream" demo application only deals with h264 files, and not real time streams. I quoted Oshi's message (which contained the questions about trick play and closed captions) because I've noticed that he wrote that he's also doing what I need (regardless of the trick play and CC), so I thought he may have already done this. Thanks. From finlayson at live555.com Wed Oct 24 11:36:08 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Oct 2012 11:36:08 -0700 Subject: [Live-devel] Streaming h264 MPEG-2 TS In-Reply-To: References: <8C80217E-093E-4516-93F0-ED64A5BDE926@live555.com> Message-ID: > I only need to use Mpeg-2 Transport Stream to stream my h264 video that is > encoded in real time, and "testH264VideoToTransportStream" demo application only > deals with h264 files, and not real time streams. That's because it is simply a demonstration application. You can change the code to read instead from your H.264 video encoder simply by changing "inputFileName". Alternatively, if your encoder is not accessible via the file system (or via a named pipe), then you can write your own class (a subclass of "FramedSource") to encapsulate it. For more information, see http://www.live555.com/liveMedia/faq.html#liveInput Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From reply2010 at yeah.net Thu Oct 25 05:54:31 2012 From: reply2010 at yeah.net (reply2010) Date: Thu, 25 Oct 2012 20:54:31 +0800 (CST) Subject: [Live-devel] rtsp server for live audio Message-ID: <4fdd66de.6f39.13a97fd02bb.Coremail.reply2010@yeah.net> Hi,respectable live555 experts I have two questions: 1,Could live555's rtsp server or other application in live555 stream for live audio such as PC microphone device?I want to stream live audio by my PC's microphone.the type of audio stream could be amr or aac or g711 etc. 2,openRTSP say as below Extracting a single stream (to 'stdout') To record only the audio stream from a session, use the "-a" command-line option. (Similarly, to record only the video stream, use the "-v" option.) In this case, the output audio (or video) stream will be written to 'stdout', rather than to a file. I want to know what is 'stdout' here. a file or a pipeline or device? thanks a lot any reply would be appreciated! best regards jegger -------------- next part -------------- An HTML attachment was scrubbed... URL: From reply2010 at yeah.net Fri Oct 26 03:46:27 2012 From: reply2010 at yeah.net (reply2010) Date: Fri, 26 Oct 2012 18:46:27 +0800 (CST) Subject: [Live-devel] rtsp server for live audio In-Reply-To: <4fdd66de.6f39.13a97fd02bb.Coremail.reply2010@yeah.net> References: <4fdd66de.6f39.13a97fd02bb.Coremail.reply2010@yeah.net> Message-ID: <75a4393a.a613.13a9cae1c08.Coremail.reply2010@yeah.net> HI, i find WindowsAudioInputDevice maybe a way to stream live audio.but i could not find any documents or examples about how to use WindowsAudioInputDevice.anyone could give me a example for WindowsAudioInputDevice. thanks At 2012-10-26 06:21:52,reply2010 wrote: Hi,respectable live555 experts I have two questions: 1,Could live555's rtsp server or other application in live555 stream for live audio such as PC microphone device?I want to stream live audio by my PC's microphone.the type of audio stream could be amr or aac or g711 etc. 2,openRTSP say as below Extracting a single stream (to 'stdout') To record only the audio stream from a session, use the "-a" command-line option. (Similarly, to record only the video stream, use the "-v" option.) In this case, the output audio (or video) stream will be written to 'stdout', rather than to a file. I want to know what is 'stdout' here. a file or a pipeline or device? thanks a lot any reply would be appreciated! best regards jegger -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Oct 28 10:50:19 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Oct 2012 13:50:19 -0400 Subject: [Live-devel] rtsp server for live audio In-Reply-To: <75a4393a.a613.13a9cae1c08.Coremail.reply2010@yeah.net> References: <4fdd66de.6f39.13a97fd02bb.Coremail.reply2010@yeah.net> <75a4393a.a613.13a9cae1c08.Coremail.reply2010@yeah.net> Message-ID: > i find WindowsAudioInputDevice maybe a way to stream live audio.but i could not find any documents or examples about how to use From : "This is an implementation of the "liveMedia" library's "AudioInputDevice" abstract class. This can be used by a Windows application to read PCM audio samples from an input device. (This project builds two libraries: "libWindowsAudioInputDevice_mixer.lib", which uses Windows' built-in mixer, and "libWindowsAudioInputDevice_noMixer.lib", which doesn't.)" You build this from the Makefile ("WindowsAudioInputDevice.mak"), the same way that you build the other projects for Windows. You then choose which of the two libraries you want, and link with it. Then, from your application, call "AudioInputDevice::createNew()", specifying the number of the desired audio input device. (Note that the project also builds two console applications: "showAudioInputPorts_noMixer.exe" and "showAudioInputPorts_mixer.exe"; you can run these to list the audio input devices on your Windows system.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic.nadeau at transport.alstom.com Mon Oct 29 07:12:56 2012 From: frederic.nadeau at transport.alstom.com (NADEAU Frederic -EXT) Date: Mon, 29 Oct 2012 14:12:56 +0000 Subject: [Live-devel] SIP & RTCP Message-ID: <887184C35EAC384EA0867D9A0D3C6B6601472132@041-DB3MPN1-016.041d.mgd.msft.net> Hi, There is a problem in the SIP implementation. RTCP report are not send to the proper address. Test were performed with live555-2012-10-24 with the following mod : --- live/groupsock/Groupsock.cpp 2012-10-24 09:07:18.000000000 -0400 +++ live-20121024-mod-siprtcp/groupsock/Groupsock.cpp 2012-10-29 08:40:44.000000000 -0400 @@ -276,7 +276,11 @@ Boolean Groupsock::output(UsageEnvironme if (DebugLevel >= 3) { env << *this << ": wrote " << bufferSize << " bytes, ttl " - << (unsigned)ttlToSend; + << (unsigned)ttlToSend << " to "; + for (destRecord* dests = fDests; dests != NULL; dests = dests->fNext) { + env << AddressString(dests->fGroupEId.groupAddress()).val() << ", " + << dests->fPort << ", "; + } if (numMembers > 0) { env << "; relayed to " << numMembers << " members"; } This allow better debugging. Also, DebugLevel was set to 3 in NetInterface.cpp. The issue is that the SIP client sent RTCP report to its own address. You'll find below: - output of unchanged(except above changes) - output of patched version - patch Configuration setup: - PC with Live555: 10.32.9.41 - PC with FreeSwich: 10.32.250.4 configure to answer any calls with music-on-hold You will notice that in playSIP-original, when a RTCP report is written, it is read back immediately. For better readability, some lines were redacted. Patch keeps track of the SDP sent by remote party(previously discarded) and modification to playSIP read back this information to properly setup RTCP report. Also, the item Max-Forwards has been added to SIP message as required by RFC3261 section 8.1.1. See patch. Bonus question: any better way to provide Live555 dev team with big text file?(attachment, pastbin, etc) ***************************************************************************************** /tmp # ./playSIP-original sip:toto at 10.32.250.4 14:24:13 Groupsock(3: 10.32.9.41, 0, 255): created Sending request: INVITE sip:toto at 10.32.250.4 SIP/2.0 From: toto ;tag=83369963 Via: SIP/2.0/UDP 10.32.9.41:32818 To: sip:toto at 10.32.250.4 Contact: sip:toto at 10.32.9.41:32818 Call-ID: 1955131746 at 10.32.9.41 CSeq: 1 INVITE Content-Type: application/sdp User-Agent: playSIP-original (LIVE555 Streaming Media v2012.10.24) Content-Length: 121 v=0 o=- 1955131746 0 IN IP4 10.32.9.41 s=playSIP-original session c=IN IP4 10.32.9.41 t=0 0 m=audio 8000 RTP/AVP 0 14:24:13 Groupsock(3: 10.32.9.41, 0, 255): wrote 472 bytes, ttl 255 to 10.32.250.4, 5060, 14:24:13 Groupsock(3: 10.32.9.41, 0, 255): read 275 bytes from 10.32.250.4 Received INVITE response: SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.32.9.41:32818 From: toto ;tag=83369963 To: Call-ID: 1955131746 at 10.32.9.41 CSeq: 1 INVITE User-Agent: FreeSWITCH-mod_sofia/1.2.0-rc2+git~20120730T235848Z~3b5b59e693 Content-Length: 0 14:24:13 Groupsock(3: 10.32.9.41, 0, 255): read 1013 bytes from 10.32.250.4 Received INVITE response: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.32.9.41:32818 From: toto ;tag=83369963 To: ;tag=34rSN3mvS765D Call-ID: 1955131746 at 10.32.9.41 CSeq: 1 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.2.0-rc2+git~20120730T235848Z~3b5b59e693 Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 189 Remote-Party-ID: "toto" ;party=calling;privacy=off;screen=no v=0 o=FreeSWITCH 1351487890 1351487891 IN IP4 10.32.250.4 s=FreeSWITCH c=IN IP4 10.32.250.4 t=0 0 m=audio 29358 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 Opened URL "sip:toto at 10.32.250.4", returning a SDP description: v=0 o=- 1955131746 0 IN IP4 10.32.9.41 s=playSIP-original session c=IN IP4 10.32.9.41 t=0 0 m=audio 8000 RTP/AVP 0 14:24:13 Groupsock(4: 10.32.9.41, 8000, 255): created 14:24:13 Groupsock(5: 10.32.9.41, 8001, 255): created Created receiver for "audio/PCMU" subsession (client ports 8000-8001) Setup "audio/PCMU" subsession (client ports 8000-8001) Created output file: "audio-PCMU-1" Sending request: ACK sip:toto at 10.32.250.4 SIP/2.0 From: toto ;tag=83369963 Via: SIP/2.0/UDP 10.32.9.41:32818 To: sip:toto at 10.32.250.4;tag=34rSN3mvS765D Call-ID: 1955131746 at 10.32.9.41 CSeq: 1 ACK Content-Length: 0 14:24:13 Groupsock(3: 10.32.9.41, 0, 255): wrote 226 bytes, ttl 255 to 10.32.250.4, 5060, Started playing session Receiving streamed data (signal with "kill -HUP 7488" or "kill -USR1 7488" to terminate)... 14:24:13 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:15 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:15 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:15 Groupsock(5: 10.32.9.41, 8001, 255): read 48 bytes from 10.32.9.41 14:24:15 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:18 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:18 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:24:18 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:21 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:21 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:21 Groupsock(5: 10.32.9.41, 8001, 255): read 48 bytes from 10.32.9.41 14:24:21 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:23 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:23 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:24:23 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:27 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:27 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:27 Groupsock(5: 10.32.9.41, 8001, 255): read 48 bytes from 10.32.9.41 14:24:27 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:28 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:28 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:24:28 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:32 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:32 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:32 Groupsock(5: 10.32.9.41, 8001, 255): read 48 bytes from 10.32.9.41 14:24:32 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:33 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:33 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:24:33 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:37 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:37 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:37 Groupsock(5: 10.32.9.41, 8001, 255): read 48 bytes from 10.32.9.41 14:24:37 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:38 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:38 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:24:38 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:43 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:43 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:43 Groupsock(5: 10.32.9.41, 8001, 255): read 48 bytes from 10.32.9.41 14:24:43 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:43 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:43 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:24:43 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:47 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:47 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:47 Groupsock(5: 10.32.9.41, 8001, 255): read 48 bytes from 10.32.9.41 14:24:47 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:48 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:48 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:24:48 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:52 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:52 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:52 Groupsock(5: 10.32.9.41, 8001, 255): read 48 bytes from 10.32.9.41 14:24:52 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:53 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:24:53 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:24:53 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:24:56 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 Got shutdown signal Sending request: BYE sip:toto at 10.32.250.4 SIP/2.0 From: toto ;tag=83369963 Via: SIP/2.0/UDP 10.32.9.41:32818 To: sip:toto at 10.32.250.4;tag=34rSN3mvS765D Call-ID: 1955131746 at 10.32.9.41 CSeq: 2 BYE Content-Length: 0 14:24:56 Groupsock(3: 10.32.9.41, 0, 255): wrote 226 bytes, ttl 255 to 10.32.250.4, 5060, 14:24:56 Groupsock(5: 10.32.9.41, 8001, 255): wrote 40 bytes, ttl 255 to 10.32.9.41, 8001, 14:24:56 Groupsock(5: 10.32.9.41, 8001, 255): deleting 14:24:56 Groupsock(4: 10.32.9.41, 8000, 255): deleting 14:24:56 Groupsock(3: 10.32.9.41, 0, 255): deleting ***************************************************************************************** /tmp # ./playSIP-mod sip:toto at 10.32.250.4 14:27:49 Groupsock(3: 10.32.9.41, 0, 255): created Sending request: INVITE sip:toto at 10.32.250.4 SIP/2.0 From: toto ;tag=798552056 Via: SIP/2.0/UDP 10.32.9.41:32818 Max-Forwards: 70 To: sip:toto at 10.32.250.4 Contact: sip:toto at 10.32.9.41:32818 Call-ID: 212035618 at 10.32.9.41 CSeq: 1 INVITE Content-Type: application/sdp User-Agent: playSIP-mod (LIVE555 Streaming Media v2012.10.24) Content-Length: 115 v=0 o=- 212035618 0 IN IP4 10.32.9.41 s=playSIP-mod session c=IN IP4 10.32.9.41 t=0 0 m=audio 8000 RTP/AVP 0 14:27:49 Groupsock(3: 10.32.9.41, 0, 255): wrote 479 bytes, ttl 255 to 10.32.250.4, 5060, 14:27:49 Groupsock(3: 10.32.9.41, 0, 255): read 275 bytes from 10.32.250.4 Received INVITE response: SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.32.9.41:32818 From: toto ;tag=798552056 To: Call-ID: 212035618 at 10.32.9.41 CSeq: 1 INVITE User-Agent: FreeSWITCH-mod_sofia/1.2.0-rc2+git~20120730T235848Z~3b5b59e693 Content-Length: 0 14:27:49 Groupsock(3: 10.32.9.41, 0, 255): read 1013 bytes from 10.32.250.4 Received INVITE response: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.32.9.41:32818 From: toto ;tag=798552056 To: ;tag=4DjjQy5ZpgXrS Call-ID: 212035618 at 10.32.9.41 CSeq: 1 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.2.0-rc2+git~20120730T235848Z~3b5b59e693 Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 189 Remote-Party-ID: "toto" ;party=calling;privacy=off;screen=no v=0 o=FreeSWITCH 1351488404 1351488405 IN IP4 10.32.250.4 s=FreeSWITCH c=IN IP4 10.32.250.4 t=0 0 m=audio 29060 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 Opened URL "sip:toto at 10.32.250.4", returning a SDP description: v=0 o=- 212035618 0 IN IP4 10.32.9.41 s=playSIP-mod session c=IN IP4 10.32.9.41 t=0 0 m=audio 8000 RTP/AVP 0 14:27:49 Groupsock(4: 10.32.9.41, 8000, 255): created 14:27:49 Groupsock(5: 10.32.9.41, 8001, 255): created Created receiver for "audio/PCMU" subsession (client ports 8000-8001) Setup "audio/PCMU" subsession (client ports 8000-8001) Created output file: "audio-PCMU-1" Sending request: ACK sip:toto at 10.32.250.4 SIP/2.0 From: toto ;tag=798552056 Via: SIP/2.0/UDP 10.32.9.41:32818 Max-Forwards: 70 To: sip:toto at 10.32.250.4;tag=4DjjQy5ZpgXrS Call-ID: 212035618 at 10.32.9.41 CSeq: 1 ACK Content-Length: 0 14:27:49 Groupsock(3: 10.32.9.41, 0, 255): wrote 244 bytes, ttl 255 to 10.32.250.4, 5060, Started playing session Receiving streamed data (signal with "kill -HUP 8081" or "kill -USR1 8081" to terminate)... 14:27:49 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:27:51 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:27:51 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.250.4, 29061, 14:27:51 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:27:54 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:27:54 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:27:54 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:27:56 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:27:56 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.250.4, 29061, 14:27:56 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:27:59 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:27:59 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:27:59 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:28:01 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:28:02 Groupsock(5: 10.32.9.41, 8001, 255): wrote 48 bytes, ttl 255 to 10.32.250.4, 29061, 14:28:02 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:28:04 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 14:28:04 Groupsock(5: 10.32.9.41, 8001, 255): read 78 bytes from 10.32.250.4 14:28:04 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 ... 14:28:07 Groupsock(4: 10.32.9.41, 8000, 255): read 172 bytes from 10.32.250.4 Got shutdown signal Sending request: BYE sip:toto at 10.32.250.4 SIP/2.0 From: toto ;tag=798552056 Via: SIP/2.0/UDP 10.32.9.41:32818 Max-Forwards: 70 To: sip:toto at 10.32.250.4;tag=4DjjQy5ZpgXrS Call-ID: 212035618 at 10.32.9.41 CSeq: 2 BYE Content-Length: 0 14:28:07 Groupsock(3: 10.32.9.41, 0, 255): wrote 244 bytes, ttl 255 to 10.32.250.4, 5060, 14:28:07 Groupsock(5: 10.32.9.41, 8001, 255): wrote 40 bytes, ttl 255 to 10.32.250.4, 29061, 14:28:07 Groupsock(5: 10.32.9.41, 8001, 255): deleting 14:28:07 Groupsock(4: 10.32.9.41, 8000, 255): deleting 14:28:07 Groupsock(3: 10.32.9.41, 0, 255): deleting ***************************************************************************************** diff -rupN live-20121024/liveMedia/include/SIPClient.hh live-20121024-mod-siprtcp/liveMedia/include/SIPClient.hh --- live-20121024/liveMedia/include/SIPClient.hh 2012-10-24 09:07:18.000000000 -0400 +++ live-20121024-mod-siprtcp/liveMedia/include/SIPClient.hh 2012-10-29 09:51:52.000000000 -0400 @@ -67,6 +67,9 @@ public: static Boolean parseSIPURLUsernamePassword(char const* url, char*& username, char*& password); + char const* getInviteSdpReply() { + return fInviteSDPDescriptionReturned; + } protected: virtual ~SIPClient(); @@ -108,34 +111,36 @@ private: // Set for all calls: unsigned char fDesiredAudioRTPPayloadFormat; char* fMIMESubtype; - unsigned fMIMESubtypeSize; + unsigned fMIMESubtypeSize; int fVerbosityLevel; unsigned fCSeq; // sequence number, used in consecutive requests char const* fApplicationName; - unsigned fApplicationNameSize; + unsigned fApplicationNameSize; char const* fOurAddressStr; - unsigned fOurAddressStrSize; + unsigned fOurAddressStrSize; portNumBits fOurPortNum; Groupsock* fOurSocket; char* fUserAgentHeaderStr; - unsigned fUserAgentHeaderStrSize; + unsigned fUserAgentHeaderStrSize; // Set for each call: char const* fURL; - unsigned fURLSize; + unsigned fURLSize; struct in_addr fServerAddress; portNumBits fServerPortNum; // in host order portNumBits fClientStartPortNum; // in host order unsigned fCallId, fFromTag; // set by us char const* fToTagStr; // set by the responder - unsigned fToTagStrSize; + unsigned fToTagStrSize; Authenticator fValidAuthenticator; char const* fUserName; // 'user' name used in "From:" & "Contact:" lines - unsigned fUserNameSize; + unsigned fUserNameSize; char* fInviteSDPDescription; + char* fInviteSDPDescriptionReturned; char* fInviteCmd; - unsigned fInviteCmdSize; + unsigned fInviteCmdSize; Authenticator* fWorkingAuthenticator; inviteClientState fInviteClientState; char fEventLoopStopFlag; diff -rupN live-20121024/liveMedia/SIPClient.cpp live-20121024-mod-siprtcp/liveMedia/SIPClient.cpp --- live-20121024/liveMedia/SIPClient.cpp 2012-10-24 09:07:18.000000000 -0400 +++ live-20121024-mod-siprtcp/liveMedia/SIPClient.cpp 2012-10-29 09:52:05.000000000 -0400 @@ -49,7 +49,8 @@ SIPClient::SIPClient(UsageEnvironment& e fCSeq(0), fURL(NULL), fURLSize(0), fToTagStr(NULL), fToTagStrSize(0), fUserName(NULL), fUserNameSize(0), - fInviteSDPDescription(NULL), fInviteCmd(NULL), fInviteCmdSize(0){ + fInviteSDPDescription(NULL), fInviteSDPDescriptionReturned(NULL), + fInviteCmd(NULL), fInviteCmdSize(0){ if (mimeSubtype == NULL) mimeSubtype = ""; fMIMESubtype = strDup(mimeSubtype); fMIMESubtypeSize = strlen(fMIMESubtype); @@ -229,6 +230,7 @@ char* SIPClient::invite1(Authenticator* + 5 /* max short len */ + 3 /* max char len */ + rtpmapLineSize; delete[] fInviteSDPDescription; + delete[] fInviteSDPDescriptionReturned; fInviteSDPDescription = new char[inviteSDPFmtSize]; sprintf(fInviteSDPDescription, inviteSDPFmt, fCallId, fCSeq, fOurAddressStr, @@ -243,6 +245,7 @@ char* SIPClient::invite1(Authenticator* "INVITE %s SIP/2.0\r\n" "From: %s ;tag=%u\r\n" "Via: SIP/2.0/UDP %s:%u\r\n" + "Max-Forwards: 70\r\n" "To: %s\r\n" "Contact: sip:%s@%s:%u\r\n" "Call-ID: %u@%s\r\n" @@ -432,6 +435,7 @@ void SIPClient::doInviteStateTerminated( if (responseCode < 200 || responseCode > 299) { // We failed, so return NULL; delete[] fInviteSDPDescription; fInviteSDPDescription = NULL; + delete[] fInviteSDPDescriptionReturned; fInviteSDPDescriptionReturned = NULL; } // Unblock the event loop: @@ -595,6 +599,7 @@ unsigned SIPClient::getResponseCode() { } bodyStart[contentLength] = '\0'; // trims any extra data + fInviteSDPDescriptionReturned = strDup(bodyStart); } } while (0); @@ -636,6 +641,7 @@ Boolean SIPClient::sendACK() { "ACK %s SIP/2.0\r\n" "From: %s ;tag=%u\r\n" "Via: SIP/2.0/UDP %s:%u\r\n" + "Max-Forwards: 70\r\n" "To: %s;tag=%s\r\n" "Call-ID: %u@%s\r\n" "CSeq: %d ACK\r\n" @@ -677,6 +683,7 @@ Boolean SIPClient::sendBYE() { "BYE %s SIP/2.0\r\n" "From: %s ;tag=%u\r\n" "Via: SIP/2.0/UDP %s:%u\r\n" + "Max-Forwards: 70\r\n" "To: %s;tag=%s\r\n" "Call-ID: %u@%s\r\n" "CSeq: %d BYE\r\n" diff -rupN live-20121024/testProgs/playSIP.cpp live-20121024-mod-siprtcp/testProgs/playSIP.cpp --- live-20121024/testProgs/playSIP.cpp 2012-10-24 09:07:18.000000000 -0400 +++ live-20121024-mod-siprtcp/testProgs/playSIP.cpp 2012-10-29 08:40:44.000000000 -0400 @@ -20,6 +20,20 @@ along with this library; if not, write t #include "playCommon.hh" #include "SIPClient.hh" +static char* getLine(char* startOfLine) { + // returns the start of the next line, or NULL if none + for (char* ptr = startOfLine; *ptr != '\0'; ++ptr) { + if (*ptr == '\r' || *ptr == '\n') { + // We found the end of the line + *ptr++ = '\0'; + if (*ptr == '\n') ++ptr; + return ptr; + } + } + + return NULL; +} + SIPClient* ourSIPClient = NULL; Medium* createClient(UsageEnvironment& env, char const* /*url*/, int verbosityLevel, char const* applicationName) { // First, trim any directory prefixes from "applicationName": @@ -82,6 +96,53 @@ void getSDPDescription(RTSPClient::respo void setupSubsession(MediaSubsession* subsession, Boolean /*streamUsingTCP*/, RTSPClient::responseHandler* afterFunc) { subsession->setSessionId("mumble"); // anything that's non-NULL will work + // Parse the "Transport:" header parameters: + // We do not send audio, but we need port for RTCP + char* serverAddressStr; + portNumBits serverPortNum; + unsigned char rtpChannelId, rtcpChannelId; + + rtpChannelId = rtcpChannelId = 0xff; + serverPortNum = 0; + serverAddressStr = NULL; + + char* sdp = strDup(ourSIPClient->getInviteSdpReply()); + + char* lineStart; + char* nextLineStart = sdp; + while (1) { + lineStart = nextLineStart; + if (lineStart == NULL) { + break; + } + nextLineStart = getLine(lineStart); + + char* toTagStr = strDupSize(lineStart); + + if (sscanf(lineStart, "m=audio %[^/\r\n]", toTagStr) == 1) { + sscanf(toTagStr, "%hu", &serverPortNum); + } else if (sscanf(lineStart, "c=IN IP4 %[^/\r\n]", toTagStr) == 1) { + serverAddressStr = strDup(toTagStr); + } + delete[] toTagStr; + } + + if(sdp != NULL) { + delete[] sdp; + } + + delete[] subsession->connectionEndpointName(); + subsession->connectionEndpointName() = serverAddressStr; + subsession->serverPortNum = serverPortNum; + subsession->rtpChannelId = rtpChannelId; + subsession->rtcpChannelId = rtcpChannelId; + + // Set the RTP and RTCP sockets' destination address and port from the information in the SETUP response (if present): + netAddressBits destAddress = subsession->connectionEndpointAddress(); + if (destAddress != 0) { + subsession->setDestinations(destAddress); + } + afterFunc(NULL, 0, NULL); } ***************************************************************************************** ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. From hackeron at gmail.com Mon Oct 29 05:23:56 2012 From: hackeron at gmail.com (Roman Gaufman) Date: Mon, 29 Oct 2012 12:23:56 +0000 Subject: [Live-devel] rtsp server for live audio In-Reply-To: References: <4fdd66de.6f39.13a97fd02bb.Coremail.reply2010@yeah.net> <75a4393a.a613.13a9cae1c08.Coremail.reply2010@yeah.net> Message-ID: Anything similar for linux? On 28 October 2012 17:50, Ross Finlayson wrote: > i find WindowsAudioInputDevice maybe a way to stream live audio.but i > could not find any documents or examples about how to use > > > From : > "This is an implementation of the "liveMedia" library's "AudioInputDevice" > abstract class. This can be used by a Windows application to read PCM audio > samples from an input device. > > (This project builds two libraries: > "libWindowsAudioInputDevice_mixer.lib", which uses Windows' built-in mixer, > and "libWindowsAudioInputDevice_noMixer.lib", which doesn't.)" > > You build this from the Makefile ("WindowsAudioInputDevice.mak"), the same > way that you build the other projects for Windows. You then choose which > of the two libraries you want, and link with it. Then, from your > application, call "AudioInputDevice::createNew()", specifying the number of > the desired audio input device. (Note that the project also builds two > console applications: "showAudioInputPorts_noMixer.exe" and > "showAudioInputPorts_mixer.exe"; you can run these to list the audio input > devices on your Windows system.) > > > 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 Mon Oct 29 21:28:13 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Oct 2012 00:28:13 -0400 Subject: [Live-devel] rtsp server for live audio In-Reply-To: References: <4fdd66de.6f39.13a97fd02bb.Coremail.reply2010@yeah.net> <75a4393a.a613.13a9cae1c08.Coremail.reply2010@yeah.net> Message-ID: <667E5FCB-0D25-4151-9439-676E50915B45@live555.com> > Anything similar for linux? No (at least, not in our source code distribution). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 30 08:50:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Oct 2012 11:50:59 -0400 Subject: [Live-devel] SIP & RTCP In-Reply-To: <887184C35EAC384EA0867D9A0D3C6B6601472132@041-DB3MPN1-016.041d.mgd.msft.net> References: <887184C35EAC384EA0867D9A0D3C6B6601472132@041-DB3MPN1-016.041d.mgd.msft.net> Message-ID: Thanks. This will be fixed in a future release of the software. > Bonus question: any better way to provide Live555 dev team with big text file?(attachment, pastbin, etc) Email attachments are usually best. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mason.winsauer at gmail.com Mon Oct 29 17:04:08 2012 From: mason.winsauer at gmail.com (Mason Winsauer) Date: Mon, 29 Oct 2012 18:04:08 -0600 Subject: [Live-devel] RTSP Support for VLC on SLES 11.2 Message-ID: <508F1978.500@gmail.com> Hello, I am working on a project to get RTSP streaming to a local Apache server. I was able to get this ironed out on a Debian-based system, but now need to port it to a SLES 11.2 box running VLC 1.1.13 [The Luggage]. However, when making VLC, after configuring it with ``--enable-live555 --with-live555-tree=/usr/local/lib/live``, I am still experiencing errors in the VLC make process that begin with: ------------- make[5]: Entering directory `/home/capturevideo/VLC/vlc-1.1.13/modules/demux' CXX liblive555_plugin_la-live555.lo live555.cpp: In function 'void Close(vlc_object_t*)': live555.cpp:438: error: 'class RTSPClient' has no member named 'teardownMediaSession' ------------- I am also using FFMPEG 0.10, and the latest live555, configured as linux-64bit. I would love some feedback, as I haven't seen much documentation on the subject, and most responses on VLC forums boil down to "There's a reason 95% of VLC users use Debian systems." Thanks! Mason From chrisballinger at gmail.com Wed Oct 31 13:45:21 2012 From: chrisballinger at gmail.com (Chris Ballinger) Date: Wed, 31 Oct 2012 13:45:21 -0700 Subject: [Live-devel] Patch for iOS 6 compilation Message-ID: I found the answer on StackOverflow ( http://stackoverflow.com/questions/11369933/live555-compile-for-ios-build-error) but it appears no one submitted a patch yet, so here it is! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.iphoneos.patch Type: application/octet-stream Size: 784 bytes Desc: not available URL: From kingaceck at 163.com Wed Oct 31 23:19:35 2012 From: kingaceck at 163.com (kingaceck) Date: Thu, 1 Nov 2012 14:19:35 +0800 Subject: [Live-devel] another case result in proxy server broken down(2) References: <201211011144002650912@163.com> Message-ID: <201211011419344376358@163.com> This case is different from previous .It can also result in proxy server broken down . 1)starting up the live555ProxyServer 2)connect to the server using vlc(rtsp://129.1.5.156/proxyStream) 3)restart the Darwion streaming server 4)connect to the live555ProxyServer using another vlc client After do this the the live555ProxyServer is also broken down. There are the logs as following: root at ck-laptop:/diske/cppworkspace/live555/source/proxyserver# ./live555ProxyServer -V rtsp://129.1.5.155/1080p.mp4 LIVE555 Proxy Server (LIVE555 Streaming Media library version 2012.10.24) Opening connection to 129.1.5.155, port 554... RTSP stream, proxying the stream "rtsp://129.1.5.155/1080p.mp4" Play this stream using the URL: rtsp://129.1.5.156/proxyStream (We use port 80 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://129.1.5.155/1080p.mp4 RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Accept: application/sdp Received 1228 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 2 Last-Modified: Thu, 27 Sep 2012 01:40:41 GMT Cache-Control: must-revalidate Content-length: 805 Date: Thu, 01 Nov 2012 06:17:32 GMT Expires: Thu, 01 Nov 2012 06:17:32 GMT Content-Type: application/sdp x-Accept-Retransmit: our-retransmit x-Accept-Dynamic-Rate: 1 Content-Base: rtsp://129.1.5.155/1080p.mp4/ v=0 o=StreamingServer 3560739452 1348710041000 IN IP4 129.1.5.155 s=\1080p.mp4 u=http:/// e=admin@ c=IN IP4 0.0.0.0 b=AS:5256 t=0 0 a=control:* a=x-copyright: MP4/3GP File hinted with GPAC 0.4.6-DEV (internal rev. 7) (C)2000-2005 - http://gpac.sourceforge.net a=range:npt=0- 291.82833 m=video 0 RTP/AVP 96 b=AS:5064 a=rtpmap:96 H264/90000 a=control:trackID=65536 a=fmtp:96 profile-level-id=640028; packetization-mode=1; sprop-parameter-sets=Z2QAKKy0A8ARPywgAAB9IAAdTAHjBlQ=,aO48sA== a=framesize:96 1920-1080 m=audio 0 RTP/AVP 97 b=AS:192 a=rtpmap:97 mpeg4-generic/44100/2 a=control:trackID=65537 a=fmtp:97 profile-level-id=41; config=12100000000000000000000000000000; streamType=5; mode=AAC-hbr; objectType=64; constantDuration=1024; sizeLength=13; indexLength=3; indexDeltaLength=3 ProxyServerMediaSession["rtsp://129.1.5.155/1080p.mp4/"] added new "ProxyServerMediaSubsession" for RTP/video/H264 track ProxyServerMediaSession["rtsp://129.1.5.155/1080p.mp4/"] added new "ProxyServerMediaSubsession" for RTP/audio/MPEG4-GENERIC track Sending request: OPTIONS rtsp://129.1.5.155/1080p.mp4/ RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Received 183 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 3 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["MPEG4-GENERIC"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["MPEG4-GENERIC"] ProxyServerMediaSubsession["MPEG4-GENERIC"]::createNewRTPSink() ProxyServerMediaSubsession["MPEG4-GENERIC"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 1674296022) Sending request: SETUP rtsp://129.1.5.155/1080p.mp4/trackID=65536 RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Transport: RTP/AVP;unicast;client_port=34282-34283 ProxyServerMediaSubsession["H264"]::createNewRTPSink() Received 395 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 4 Last-Modified: Thu, 27 Sep 2012 01:40:41 GMT Cache-Control: must-revalidate Session: 91787746099909 Date: Thu, 01 Nov 2012 06:17:32 GMT Expires: Thu, 01 Nov 2012 06:17:32 GMT Transport: RTP/AVP;unicast;source=129.1.5.155;client_port=34282-34283;server_port=6970-6971;ssrc=00000E9E ProxyRTSPClient["rtsp://129.1.5.155/1080p.mp4/"]::continueAfterSETUP(): head codec: H264; numSubsessions 2 queue: H264 ProxyServerMediaSubsession["MPEG4-GENERIC"]::createNewStreamSource(session id 1674296022) Sending request: SETUP rtsp://129.1.5.155/1080p.mp4/trackID=65537 RTSP/1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Transport: RTP/AVP;unicast;client_port=34300-34301 Session: 91787746099909 ProxyServerMediaSubsession["MPEG4-GENERIC"]::createNewRTPSink() Received 395 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 5 Session: 91787746099909 Last-Modified: Thu, 27 Sep 2012 01:40:41 GMT Cache-Control: must-revalidate Date: Thu, 01 Nov 2012 06:17:32 GMT Expires: Thu, 01 Nov 2012 06:17:32 GMT Transport: RTP/AVP;unicast;source=129.1.5.155;client_port=34300-34301;server_port=6970-6971;ssrc=00003776 ProxyRTSPClient["rtsp://129.1.5.155/1080p.mp4/"]::continueAfterSETUP(): head codec: MPEG4-GENERIC; numSubsessions 2 queue: MPEG4-GENERIC Sending request: PLAY rtsp://129.1.5.155/1080p.mp4/ RTSP/1.0 CSeq: 6 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Session: 91787746099909 Received 316 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 6 Session: 91787746099909 Range: npt=0.00000-291.82833 RTP-Info: url=rtsp://129.1.5.155/1080p.mp4/trackID=65536;seq=25084;rtptime=10678,url=rtsp://129.1.5.155/1080p.mp4/trackID=65537;seq=26382;rtptime=22011 Sending request: OPTIONS rtsp://129.1.5.155/1080p.mp4/ RTSP/1.0 CSeq: 7 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Received 183 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 7 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD ProxyServerMediaSubsession["MPEG4-GENERIC"]: received RTCP "BYE" ProxyServerMediaSubsession["MPEG4-GENERIC"]::closeStreamSource() Sending request: PAUSE rtsp://129.1.5.155/1080p.mp4/ RTSP/1.0 CSeq: 8 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Session: 91787746099909 ProxyServerMediaSubsession["H264"]: received RTCP "BYE" ProxyServerMediaSubsession["H264"]::closeStreamSource() Received 169 new bytes of response data. Received a complete PAUSE response: RTSP/1.0 503 Service Unavailable Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 8 Session: 91787746099909 Connection: Close ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["MPEG4-GENERIC"]::closeStreamSource() Opening connection to 129.1.5.155, port 554... ...remote connection opened Sending request: OPTIONS rtsp://129.1.5.155/1080p.mp4/ RTSP/1.0 CSeq: 9 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Received 183 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 9 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD Sending request: OPTIONS rtsp://129.1.5.155/1080p.mp4/ RTSP/1.0 CSeq: 10 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Received 184 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 10 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 3844241543) Sending request: PLAY rtsp://129.1.5.155/1080p.mp4/ RTSP/1.0 CSeq: 11 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.10.24) Session: 91787746099909 ProxyServerMediaSubsession["H264"]::createNewRTPSink() Received 172 new bytes of response data. Received a complete PLAY response: RTSP/1.0 500 Internal Server Error Server: DSS/5.5.5 (Build/489.16; Platform/Win32; Release/Darwin; state/beta; ) Cseq: 11 Session: 91787746099909 Connection: Close ProxyServerMediaSubsession["MPEG4-GENERIC"]::createNewStreamSource(session id 3844241543) ProxyServerMediaSubsession["MPEG4-GENERIC"]::createNewRTPSink() FramedSource[0x9f1f2d8]::getNextFrame(): attempting to read more than once at the same time! Aborted 2012-11-01 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: