From john95018 at gmail.com Sun Feb 2 09:28:14 2014 From: john95018 at gmail.com (john dicostanzo) Date: Sun, 2 Feb 2014 22:58:14 +0530 Subject: [Live-devel] regarding test app MPEG2TransportStreamIndexer Message-ID: HI, I am using test app MPEG2TransportStreamIndexer. In file MPEG2IndexFromTransportStream.cpp,when it got error "Unexpectedly large PES header size" its close all handles and goes down. i want to catch this error in test app and perform action on it. so can i catch this error??? Regards, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From nambirajan.manickam at i-velozity.com Wed Feb 5 05:56:51 2014 From: nambirajan.manickam at i-velozity.com (Nambirajan) Date: Wed, 5 Feb 2014 19:26:51 +0530 Subject: [Live-devel] Play response setting in Live555 Server References: <004701cf1cc6$e0c5b770$a2512650$@manickam@i-velozity.com> <006001cf1cd6$2bc036b0$8340a410$@manickam@i-velozity.com> <1466CC06-04E7-4D7E-9735-26A32993C5B4@live555.com> Message-ID: <001401cf227a$220f3450$662d9cf0$@manickam@i-velozity.com> Hi Ross, Is it possible to get the current play time while doing FFW and REW in the Play response from the Server. Best Regards, M. Nambirajan From: Nambirajan [mailto:nambirajan.manickam at i-velozity.com] Sent: Friday, January 31, 2014 1:33 PM To: 'LIVE555 Streaming Media - development & use' Subject: RE: [Live-devel] Play response setting in Live555 Server Hi Ross, Thanks for update and the fix. It is now working fine. Best Regards, M. Nambirajan From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, January 30, 2014 3:04 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Play response setting in Live555 Server Thanks for your reply. We are using unmodified code. We want to send the current play time in the play response to the player when the player sends only the range end without specifying the range start in the Range Header. Thanks for the note. It turns out that our RTSP server implementation wasn't handling this kind of "Range:" header properly. I've just installed a new version - 2014.01.29 - of the "LIVE555 Streaming Media" code that fixes this. It will set the 'current play time' as the start time in the "PLAY" response. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Feb 5 10:45:56 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Feb 2014 10:45:56 -0800 Subject: [Live-devel] Play response setting in Live555 Server In-Reply-To: <001401cf227a$220f3450$662d9cf0$@manickam@i-velozity.com> References: <004701cf1cc6$e0c5b770$a2512650$@manickam@i-velozity.com> <006001cf1cd6$2bc036b0$8340a410$@manickam@i-velozity.com> <1466CC06-04E7-4D7E-9735-26A32993C5B4@live555.com> <001401cf227a$220f3450$662d9cf0$@manickam@i-velozity.com> Message-ID: <4B77F37E-3312-4420-A52D-DFD8A99BA993@live555.com> > Is it possible to get the current play time while doing FFW and REW in the Play response from the Server. The server should now be doing that. Please post an example of the "PLAY" command that you're sending, and the server's current response. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nambirajan.manickam at i-velozity.com Thu Feb 6 01:03:11 2014 From: nambirajan.manickam at i-velozity.com (Nambirajan) Date: Thu, 6 Feb 2014 14:33:11 +0530 Subject: [Live-devel] Play response setting in Live555 Server In-Reply-To: <4B77F37E-3312-4420-A52D-DFD8A99BA993@live555.com> References: <004701cf1cc6$e0c5b770$a2512650$@manickam@i-velozity.com> <006001cf1cd6$2bc036b0$8340a410$@manickam@i-velozity.com> <1466CC06-04E7-4D7E-9735-26A32993C5B4@live555.com> <001401cf227a$220f3450$662d9cf0$@manickam@i-velozity.com> <4B77F37E-3312-4420-A52D-DFD8A99BA993@live555.com> Message-ID: <003501cf231a$44dcb2f0$ce9618d0$@manickam@i-velozity.com> Hi Ross, Please find below the details of player request and the corresponding Server response of the player in FFW and REW condition. We are using the latest version of the code. Normal Play: RTSPClientConnection[0x11fbc40]::handleRequestBytes() read 138 new bytes:PLAY rtsp://192.168.128.51:554/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts RTSP/1.0 CSeq: 3 Session: 70554585 Range: npt=190-7828 parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "", urlSuffix "OzTheGreatandHD_06112013_USA_movie_5625_CC.ts", CSeq "3", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 3 Date: Thu, Feb 06 2014 00:33:55 GMT Range: npt=190.000-7828.000 Session: 70554585 RTP-Info: url=rtsp://192.168.128.51/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts/trac k1;seq=53194;rtptime=1624948933 FFW x2: RTSPClientConnection[0x11fbc40]::handleRequestBytes() read 146 new bytes:PLAY rtsp://192.168.128.51:554/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts RTSP/1.0 Scale: 2 CSeq: 8 Session: 70554585 Range: npt= -7828 parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "", urlSuffix "OzTheGreatandHD_06112013_USA_movie_5625_CC.ts", CSeq "8", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 8 Date: Thu, Feb 06 2014 00:34:19 GMT Scale: 2.000000 Range: npt=214.000-7828.000 Session: 70554585 RTP-Info: url=rtsp://192.168.128.51/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts/trac k1;seq=820;rtptime=1627160741 FFW x4: RTSPClientConnection[0x11fbc40]::handleRequestBytes() read 147 new bytes:PLAY rtsp://192.168.128.51:554/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts RTSP/1.0 Scale: 4 CSeq: 12 Session: 70554585 Range: npt= -7828 parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "", urlSuffix "OzTheGreatandHD_06112013_USA_movie_5625_CC.ts", CSeq "12", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 12 Date: Thu, Feb 06 2014 00:34:36 GMT Scale: 4.000000 Range: npt=229.000-7828.000 Session: 70554585 RTP-Info: url=rtsp://192.168.128.51/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts/trac k1;seq=4864;rtptime=3743028388 REW x -2 RTSPClientConnection[0x11fbc40]::handleRequestBytes() read 145 new bytes:PLAY rtsp://192.168.128.51:554/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts RTSP/1.0 Scale: -2 CSeq: 16 Session: 70554585 Range: npt= -0 parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "", urlSuffix "OzTheGreatandHD_06112013_USA_movie_5625_CC.ts", CSeq "16", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 16 Date: Thu, Feb 06 2014 00:34:54 GMT Scale: -2.000000 Range: npt=-0.000-0.000 Session: 70554585 RTP-Info: url=rtsp://192.168.128.51/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts/trac k1;seq=12388;rtptime=1569795993 WE are getting the normal play response only when we do FFW. In REW we are getting 0 as npt value. Can you please check and let us know. Thanks and regards, M. Nambirajan From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, February 06, 2014 12:16 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Play response setting in Live555 Server Is it possible to get the current play time while doing FFW and REW in the Play response from the Server. The server should now be doing that. Please post an example of the "PLAY" command that you're sending, and the server's current response. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From goelli at goelli.de Thu Feb 6 16:15:51 2014 From: goelli at goelli.de (=?iso-8859-1?Q?Thomas_G=F6llner?=) Date: Fri, 7 Feb 2014 01:15:51 +0100 Subject: [Live-devel] Boolean Groupsock::deleteIfNoMembers; Message-ID: <004301cf2399$c2b209d0$48161d70$@goelli.de> Hi all, I'm wondering why there is a "Boolean Groupsock::deleteIfNoMembers;" when it is never used... I think for operations on limited hardware it is a good idea to delete the groupsock when it is no longer needed instead of keeping it alive in case it would be used in future. Thanks, Thomas G?llner From finlayson at live555.com Thu Feb 6 17:07:22 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Feb 2014 17:07:22 -0800 Subject: [Live-devel] Boolean Groupsock::deleteIfNoMembers; In-Reply-To: <004301cf2399$c2b209d0$48161d70$@goelli.de> References: <004301cf2399$c2b209d0$48161d70$@goelli.de> Message-ID: <78B224F0-822C-4E70-BE8F-41012DF5C09B@live555.com> > I'm wondering why there is a "Boolean Groupsock::deleteIfNoMembers;" when it > is never used... It's not used elsewhere within the "LIVE555 Streaming Media" software, but it is used by other Live Networks code (for UDP multicast tunneling). (In any case, this is a moot point, because the "groupsock" library is going to get completely replaced at some point in the future.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Feb 6 18:52:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Feb 2014 18:52:38 -0800 Subject: [Live-devel] Stream WAV audio over RTP In-Reply-To: References: Message-ID: <6C3E8D7E-C317-4D05-A787-36A9601588EC@live555.com> > I am writing an application which I would like to stream 8 and 16 bit pcm audio from wav files over rtp to a receiver elsewhere on my network. The control mechanism for this however will eventually be snmp (with SAP messages for the reciever configuration) rather than rtcp so I would like the stream to simply be rtp. > > I have seen the example program 'testWAVAudioStreamer' which is clearly very close to my needs however using rtsp. > > I was wondering whether there is an example available to use the libraries to send out rtp without the control protocol? Kevin, Sorry for the delay in responding. Because the "test*Streamer" applications (including "testWAVAudioStreamer") transmit using IP multicast rather than IP unicast, receiving applications *do not* need to use RTSP. RTSP just happens to be a convenient way for a receiving application to get the stream's SDP description. (This is especially true for "testWAVAudioStreamer", because the SDP description depends upon the properties of the particular WAV audio file that it's streaming. But there's no reason why the multicast streaming application (e.g., "testWAVAudioStreamer") can't make the SDP description available some other way - e.g., via SAP. To do this, add the following code at line 214 of "testProgs/testWAVAudioStreamer.cpp": char* ourSDPDescription = sms->generateSDPDescription(); This will give you a SDP description string that you can announce using SAP. (We don't provide code for SAP announcing; you'd have to write that yourself.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Feb 6 18:53:50 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Feb 2014 18:53:50 -0800 Subject: [Live-devel] regarding test app MPEG2TransportStreamIndexer In-Reply-To: References: Message-ID: <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> > I am using test app MPEG2TransportStreamIndexer. > In file MPEG2IndexFromTransportStream.cpp,when it got error "Unexpectedly large PES header size" its close all handles and goes down. John, Thanks for the note. Please put your Transport Stream file (the one that produces this error) on a (publically-accessible) web server, and send us the URL, so we can download it and test it ourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From D.Wilder at f5.com Thu Feb 6 23:21:51 2014 From: D.Wilder at f5.com (Dave Wilder) Date: Fri, 7 Feb 2014 07:21:51 +0000 Subject: [Live-devel] add a delay in between the RTSP SETUP message and corresponding RTP SETUP message Message-ID: Hello, When using openRTSP to set up an RTSP connection, is it possible to add a delay in between the RTSP SETUP message and the corresponding RTP SETUP message i.e. send the RTSP SETUP message, delay "N" seconds and then send the RTP SETUP message? Thank you, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From goelli at goelli.de Fri Feb 7 04:26:38 2014 From: goelli at goelli.de (=?iso-8859-1?Q?Thomas_G=F6llner?=) Date: Fri, 7 Feb 2014 13:26:38 +0100 Subject: [Live-devel] Boolean Groupsock::deleteIfNoMembers; Message-ID: <000601cf23ff$d962b0b0$8c281210$@goelli.de> Thanks Ross for this quick response. It's a good hint, that the "groupsock" library will be replaced. So it is useless, I think, to provide a patch for this. As a workaround I subclass the ServerMediaSubsessions I need and add something like that: virtual void closeStreamSource(FramedSource* inputSource) { Medium::close(inputSource); if (fInputGroupsock->members().IsEmpty() && fInputGroupsock->deleteIfNoMembers) { delete fInputGroupsock; fInputGroupsock = NULL; } } Best regards, Thomas G?llner From warren at etr-usa.com Fri Feb 7 12:42:33 2014 From: warren at etr-usa.com (Warren Young) Date: Fri, 07 Feb 2014 13:42:33 -0700 Subject: [Live-devel] regarding test app MPEG2TransportStreamIndexer In-Reply-To: <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> References: <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> Message-ID: <52F54539.7040403@etr-usa.com> On 2/6/2014 19:53, Ross Finlayson wrote: >> I am using test app MPEG2TransportStreamIndexer. >> In file MPEG2IndexFromTransportStream.cpp,when it got error >> "Unexpectedly large PES header size" its close all handles and goes down. > > Please put your Transport Stream file (the one that produces this error) > on a (publically-accessible) web server, and send us the URL, so we can > download it and test it ourself. We've seen this, too. URLs coming via private email. From brilliantov at byterg.ru Thu Feb 6 06:53:53 2014 From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich) Date: Thu, 06 Feb 2014 18:53:53 +0400 Subject: [Live-devel] RTSPoverHTTP: server answer example Message-ID: <52F3A201.7020200@byterg.ru> Hello! I use live555 2014.01.29. I configure RTSP server on support HTTP and after start it I see what it bind on rtsp and http port. I use vlc 1.1.3 Luggage for see video. I successfully connect to stream use RTSP URL, but I can't see stream via HTTP URL, server return "HTTP/1.1 405 Method Not Allowed". I found what live555 not support requests to access streams via HTTP (void RTSPServer::RTSPClientConnection::handleHTTPCmd_StreamingGET(char const* /*urlSuffix*/, char const* /*fullRequestStr*/)). Where can I found example for server answer, unfortunally I can't found this information? Can you help me? Thank you and excuse me for my bad english. -- Best regards, Brilliantov Kirill Vladimirovich From megaplace at hotmail.com Thu Feb 6 22:19:43 2014 From: megaplace at hotmail.com (Krishna Patel) Date: Fri, 7 Feb 2014 06:19:43 +0000 Subject: [Live-devel] Bad "Range:" header error introduced In-Reply-To: <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> References: , <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> Message-ID: Hi, I switched from Live555 version 2013.09.08 to 2014.02.04 and PLAY command sent to Axis 213 camera now results in "Bad "Range:" header" error returned by Live555. "Range: npt=now-" is returned by the camera that seems to get rejected. The camera is on-line and can be accessed via HTTP tunneling: rtsp://128.197.178.101/mpeg4/media.amp. Version 2013.09.08 worked just fine. Thanks, Krishna. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Feb 7 13:27:09 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 Feb 2014 10:27:09 +1300 Subject: [Live-devel] Play response setting in Live555 Server In-Reply-To: <003501cf231a$44dcb2f0$ce9618d0$@manickam@i-velozity.com> References: <004701cf1cc6$e0c5b770$a2512650$@manickam@i-velozity.com> <006001cf1cd6$2bc036b0$8340a410$@manickam@i-velozity.com> <1466CC06-04E7-4D7E-9735-26A32993C5B4@live555.com> <001401cf227a$220f3450$662d9cf0$@manickam@i-velozity.com> <4B77F37E-3312-4420-A52D-DFD8A99BA993@live555.com> <003501cf231a$44dcb2f0$ce9618d0$@manickam@i-velozity.com> Message-ID: <15AB1C2C-8C6A-4A5C-AB55-075000CBFBBE@live555.com> > REW x -2 > > RTSPClientConnection[0x11fbc40]::handleRequestBytes() read 145 new bytes:PLAY rtsp://192.168.128.51:554/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts RTSP/1.0 > Scale: -2 > CSeq: 16 > Session: 70554585 > Range: npt= -0 > > > parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "", urlSuffix "OzTheGreatandHD_06112013_USA_movie_5625_CC.ts", CSeq "16", Content-Length 0, with 0 bytes following the message. > sending response: RTSP/1.0 200 OK > CSeq: 16 > Date: Thu, Feb 06 2014 00:34:54 GMT > Scale: -2.000000 > Range: npt=-0.000-0.000 Thanks for the report. I've just released a new version - 2014.02.07 - of the "LIVE555 Streaming Media" code that should fix this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Feb 7 13:32:42 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 Feb 2014 10:32:42 +1300 Subject: [Live-devel] add a delay in between the RTSP SETUP message and corresponding RTP SETUP message In-Reply-To: References: Message-ID: <08DA9682-6F9D-4AAE-909B-3B0025EF88ED@live555.com> > When using openRTSP to set up an RTSP connection, is it possible to add a delay in between the RTSP SETUP message and the corresponding > RTP SETUP message i.e. send the RTSP SETUP message, delay ?N? seconds and then send the RTP SETUP message? Yes, you could do this by modifying the "continueAfterSETUP()" function to call "env->taskScheduler().scheduleDelayedTask( ... )" instead of calling "setupStreams()" (to do the next "SETUP"). Instead, your delayed function (that you specified in the call to "scheduleDelayedTask()") would call "setupStreams()". I'm not sure why you want to do this, though. (Our RTSP server implementation certainly doesn't need such a delay.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Feb 7 13:35:53 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 Feb 2014 10:35:53 +1300 Subject: [Live-devel] RTSPoverHTTP: server answer example In-Reply-To: <52F3A201.7020200@byterg.ru> References: <52F3A201.7020200@byterg.ru> Message-ID: > I use vlc 1.1.3 Luggage for see video. > I successfully connect to stream use RTSP URL, > but I can't see stream via HTTP URL, server return "HTTP/1.1 405 Method > Not Allowed". To access a stream using RTSP-over-HTTP, you must still use a "rtsp://" URL, *not* a "http://" URL. For example, using "openRTSP" (which is better than VLC for testing access to a RTSP server), you would do openRTSP -T 80 rtsp://URL (assuming that port 80 is the HTTP port that you're tunneling over). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Feb 7 13:39:34 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 Feb 2014 10:39:34 +1300 Subject: [Live-devel] Bad "Range:" header error introduced In-Reply-To: References: , <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> Message-ID: <2539FDB1-F5DC-4636-9820-A83C7A805CF3@live555.com> > I switched from Live555 version 2013.09.08 to 2014.02.04 and PLAY command sent to Axis 213 camera now results in "Bad "Range:" header" error returned by Live555. "Range: npt=now-" is returned by the camera that seems to get rejected. The camera is on-line and can be accessed via HTTP tunneling: rtsp://128.197.178.101/mpeg4/media.amp. That's odd. I'm not seeing this at all. Running "openRTSP -T 80" (to specify RTSP-over-HTTP tunneling) on this URL works just fine: %openRTSP -T 80 rtsp://128.197.178.101/mpeg4/media.amp Opening connection to 128.197.178.101, port 80... ...remote connection opened Requesting RTSP-over-HTTP tunneling (on port 80) Sending request: GET /mpeg4/media.amp HTTP/1.1 CSeq: 1 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Host: 128.197.178.101 x-sessioncookie: 11828aef671cfcf975c137d Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Received 63 new bytes of response data. Received a complete GET response: HTTP/1.0 200 OK Content-Type: application/x-rtsp-tunnelled Opening connection to 128.197.178.101, port 80... ...remote connection opened Sending request: POST /mpeg4/media.amp HTTP/1.1 CSeq: 1 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Host: 128.197.178.101 x-sessioncookie: 11828aef671cfcf975c137d Content-Type: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Content-Length: 32767 Expires: Sun, 9 Jan 1972 00:00:00 GMT Sending request: OPTIONS rtsp://128.197.178.101/mpeg4/media.amp RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) The request was base-64 encoded to: T1BUSU9OUyBydHNwOi8vMTI4LjE5Ny4xNzguMTAxL21wZWc0L21lZGlhLmFtcCBSVFNQLzEuMA0KQ1NlcTogMg0KVXNlci1BZ2VudDogLi9vcGVuUlRTUCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTQuMDIuMDcpDQoNCg== Received 91 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Public: DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, TEARDOWN Sending request: DESCRIBE rtsp://128.197.178.101/mpeg4/media.amp RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Accept: application/sdp The request was base-64 encoded to: REVTQ1JJQkUgcnRzcDovLzEyOC4xOTcuMTc4LjEwMS9tcGVnNC9tZWRpYS5hbXAgUlRTUC8xLjANCkNTZXE6IDMNClVzZXItQWdlbnQ6IC4vb3BlblJUU1AgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDE0LjAyLjA3KQ0KQWNjZXB0OiBhcHBsaWNhdGlvbi9zZHANCg0K Received 823 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Content-Base: rtsp://128.197.178.101:554/mpeg4/media.amp/ Content-Type: application/sdp Content-Length: 684 v=0 o=- 1391790981113890 1391790981113897 IN IP4 128.197.178.101 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 b=AS:8000 t=0 0 a=control:* a=range:npt=now- a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAGCQEAAAAAAAAAAA==" m=video 0 RTP/AVP 96 b=AS:8000 a=control:trackID=1 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245; config=000001B0F5000001B5090000010000000120008C4019285820F0A21F; a=mpeg4-esid:201 Opened URL "rtsp://128.197.178.101/mpeg4/media.amp", returning a SDP description: v=0 o=- 1391790981113890 1391790981113897 IN IP4 128.197.178.101 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 b=AS:8000 t=0 0 a=control:* a=range:npt=now- a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAGCQEAAAAAAAAAAA==" m=video 0 RTP/AVP 96 b=AS:8000 a=control:trackID=1 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245; config=000001B0F5000001B5090000010000000120008C4019285820F0A21F; a=mpeg4-esid:201 Created receiver for "video/MP4V-ES" subsession (client ports 51914-51915) Sending request: SETUP rtsp://128.197.178.101:554/mpeg4/media.amp/trackID=1 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 The request was base-64 encoded to: U0VUVVAgcnRzcDovLzEyOC4xOTcuMTc4LjEwMTo1NTQvbXBlZzQvbWVkaWEuYW1wL3RyYWNrSUQ9MSBSVFNQLzEuMA0KQ1NlcTogNA0KVXNlci1BZ2VudDogLi9vcGVuUlRTUCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTQuMDIuMDcpDQpUcmFuc3BvcnQ6IFJUUC9BVlAvVENQO3VuaWNhc3Q7aW50ZXJsZWF2ZWQ9MC0xDQoNCg== Received 120 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Session: 1825287805;timeout=60 Transport: RTP/AVP/TCP;unicast;mode=play;interleaved=24-25 Setup "video/MP4V-ES" subsession (client ports 51914-51915) Created output file: "video-MP4V-ES-1" Sending request: PLAY rtsp://128.197.178.101:554/mpeg4/media.amp/ RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Session: 1825287805 Range: npt=0.000- The request was base-64 encoded to: UExBWSBydHNwOi8vMTI4LjE5Ny4xNzguMTAxOjU1NC9tcGVnNC9tZWRpYS5hbXAvIFJUU1AvMS4wDQpDU2VxOiA1DQpVc2VyLUFnZW50OiAuL29wZW5SVFNQIChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxNC4wMi4wNykNClNlc3Npb246IDE4MjUyODc4MDUNClJhbmdlOiBucHQ9MC4wMDAtDQoNCg== Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Session: 1825287805 Range: npt=now- RTP-Info: url=trackID=1;seq=52465;rtptime=806046324 Started playing session Receiving streamed data (signal with "kill -HUP 93865" or "kill -USR1 93865" to terminate)... ------ So, I can't explain why it's not working for you. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From D.Wilder at f5.com Fri Feb 7 14:00:31 2014 From: D.Wilder at f5.com (Dave Wilder) Date: Fri, 7 Feb 2014 22:00:31 +0000 Subject: [Live-devel] add a delay in between the RTSP SETUP message and corresponding RTP SETUP message In-Reply-To: <08DA9682-6F9D-4AAE-909B-3B0025EF88ED@live555.com> References: <08DA9682-6F9D-4AAE-909B-3B0025EF88ED@live555.com> Message-ID: Thanks Ross. As part of testing our RTSP product, we need to do some negative testing after the RTSP connection is set-up but before the RTP connection is set up. Dave From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, February 07, 2014 4:33 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] add a delay in between the RTSP SETUP message and corresponding RTP SETUP message When using openRTSP to set up an RTSP connection, is it possible to add a delay in between the RTSP SETUP message and the corresponding RTP SETUP message i.e. send the RTSP SETUP message, delay "N" seconds and then send the RTP SETUP message? Yes, you could do this by modifying the "continueAfterSETUP()" function to call "env->taskScheduler().scheduleDelayedTask( ... )" instead of calling "setupStreams()" (to do the next "SETUP"). Instead, your delayed function (that you specified in the call to "scheduleDelayedTask()") would call "setupStreams()". I'm not sure why you want to do this, though. (Our RTSP server implementation certainly doesn't need such a delay.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From megaplace at hotmail.com Sat Feb 8 10:24:58 2014 From: megaplace at hotmail.com (Krishna Patel) Date: Sat, 8 Feb 2014 18:24:58 +0000 Subject: [Live-devel] Bad "Range:" header error introduced In-Reply-To: <2539FDB1-F5DC-4636-9820-A83C7A805CF3@live555.com> References: , , <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com>, , <2539FDB1-F5DC-4636-9820-A83C7A805CF3@live555.com> Message-ID: This is really strange. I compiled openRTSP with Visual Studio 2008. This is app output: Opening connection to 128.197.178.101, port 80... ...remote connection opened Requesting RTSP-over-HTTP tunneling (on port 80) Sending request: GET /mpeg4/media.amp HTTP/1.1 CSeq: 1 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.04) Host: 128.197.178.101 x-sessioncookie: 04f86c4ff28f926de9b83f5 Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Received 63 new bytes of response data. Received a complete GET response: HTTP/1.0 200 OK Content-Type: application/x-rtsp-tunnelled Opening connection to 128.197.178.101, port 80... ...remote connection opened Sending request: POST /mpeg4/media.amp HTTP/1.1 CSeq: 1 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.04) Host: 128.197.178.101 x-sessioncookie: 04f86c4ff28f926de9b83f5 Content-Type: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Content-Length: 32767 Expires: Sun, 9 Jan 1972 00:00:00 GMT Sending request: OPTIONS rtsp://128.197.178.101/mpeg4/media.amp RTSP/1.0 CSeq: 2 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.04) The request was base-64 encoded to: T1BUSU9OUyBydHNwOi8vMTI4LjE5Ny4xNzgu MTAxL21wZWc0L21lZGlhLmFtcCBSVFNQLzEuMA0KQ1NlcTogMg0KVXNlci1BZ2VudDogb3BlblJUU1Ag KExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDE0LjAyLjA0KQ0KDQo= Received 91 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Public: DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, TEARDOWN Sending request: DESCRIBE rtsp://128.197.178.101/mpeg4/media.amp RTSP/1.0 CSeq: 3 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.04) Accept: application/sdp The request was base-64 encoded to: REVTQ1JJQkUgcnRzcDovLzEyOC4xOTcuMTc4 LjEwMS9tcGVnNC9tZWRpYS5hbXAgUlRTUC8xLjANCkNTZXE6IDMNClVzZXItQWdlbnQ6IG9wZW5SVFNQ IChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxNC4wMi4wNCkNCkFjY2VwdDogYXBwbGljYXRpb24v c2RwDQoNCg== Received 823 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Content-Base: rtsp://128.197.178.101:554/mpeg4/media.amp/ Content-Type: application/sdp Content-Length: 684 v=0 o=- 1391865650758305 1391865650758312 IN IP4 128.197.178.101 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 b=AS:8000 t=0 0 a=control:* a=range:npt=now- a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFw cGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJ QUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlv bi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAG CQEAAAAAAAAAAA==" m=video 0 RTP/AVP 96 b=AS:8000 a=control:trackID=1 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245; config=000001B0F5000001B5090000010000000120008C4 019285820F0A21F; a=mpeg4-esid:201 Opened URL "rtsp://128.197.178.101/mpeg4/media.amp", returning a SDP description : v=0 o=- 1391865650758305 1391865650758312 IN IP4 128.197.178.101 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 b=AS:8000 t=0 0 a=control:* a=range:npt=now- a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFw cGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJ QUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlv bi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAG CQEAAAAAAAAAAA==" m=video 0 RTP/AVP 96 b=AS:8000 a=control:trackID=1 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245; config=000001B0F5000001B5090000010000000120008C4 019285820F0A21F; a=mpeg4-esid:201 Created receiver for "video/MP4V-ES" subsession (client ports 55900-55901) Sending request: SETUP rtsp://128.197.178.101:554/mpeg4/media.amp/trackID=1 RTSP /1.0 CSeq: 4 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.04) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 The request was base-64 encoded to: U0VUVVAgcnRzcDovLzEyOC4xOTcuMTc4LjEw MTo1NTQvbXBlZzQvbWVkaWEuYW1wL3RyYWNrSUQ9MSBSVFNQLzEuMA0KQ1NlcTogNA0KVXNlci1BZ2Vu dDogb3BlblJUU1AgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDE0LjAyLjA0KQ0KVHJhbnNwb3J0 OiBSVFAvQVZQL1RDUDt1bmljYXN0O2ludGVybGVhdmVkPTAtMQ0KDQo= Received 120 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Session: 1767047643;timeout=60 Transport: RTP/AVP/TCP;unicast;mode=play;interleaved=60-61 Setup "video/MP4V-ES" subsession (client ports 55900-55901) Created output file: "video-MP4V-ES-1" Sending request: PLAY rtsp://128.197.178.101:554/mpeg4/media.amp/ RTSP/1.0 CSeq: 5 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.04) Session: 1767047643 Range: npt=0.000- The request was base-64 encoded to: UExBWSBydHNwOi8vMTI4LjE5Ny4xNzguMTAx OjU1NC9tcGVnNC9tZWRpYS5hbXAvIFJUU1AvMS4wDQpDU2VxOiA1DQpVc2VyLUFnZW50OiBvcGVuUlRT UCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTQuMDIuMDQpDQpTZXNzaW9uOiAxNzY3MDQ3NjQz DQpSYW5nZTogbnB0PTAuMDAwLQ0KDQo= Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Session: 1767047643 Range: npt=now- RTP-Info: url=trackID=1;seq=34609;rtptime=3603019675 Failed to start playing session: Bad "Range:" header Sending request: TEARDOWN rtsp://128.197.178.101:554/mpeg4/media.amp/ RTSP/1.0 CSeq: 6 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.04) Session: 1767047643 The request was base-64 encoded to: VEVBUkRPV04gcnRzcDovLzEyOC4xOTcuMTc4 LjEwMTo1NTQvbXBlZzQvbWVkaWEuYW1wLyBSVFNQLzEuMA0KQ1NlcTogNg0KVXNlci1BZ2VudDogb3Bl blJUU1AgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDE0LjAyLjA0KQ0KU2Vzc2lvbjogMTc2NzA0 NzY0Mw0KDQo= Krishna. From: finlayson at live555.com Date: Sat, 8 Feb 2014 10:39:34 +1300 To: live-devel at ns.live555.com Subject: Re: [Live-devel] Bad "Range:" header error introduced I switched from Live555 version 2013.09.08 to 2014.02.04 and PLAY command sent to Axis 213 camera now results in "Bad "Range:" header" error returned by Live555. "Range: npt=now-" is returned by the camera that seems to get rejected. The camera is on-line and can be accessed via HTTP tunneling: rtsp://128.197.178.101/mpeg4/media.amp. That's odd. I'm not seeing this at all. Running "openRTSP -T 80" (to specify RTSP-over-HTTP tunneling) on this URL works just fine: %openRTSP -T 80 rtsp://128.197.178.101/mpeg4/media.amp Opening connection to 128.197.178.101, port 80... ...remote connection opened Requesting RTSP-over-HTTP tunneling (on port 80) Sending request: GET /mpeg4/media.amp HTTP/1.1 CSeq: 1 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Host: 128.197.178.101 x-sessioncookie: 11828aef671cfcf975c137d Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Received 63 new bytes of response data. Received a complete GET response: HTTP/1.0 200 OK Content-Type: application/x-rtsp-tunnelled Opening connection to 128.197.178.101, port 80... ...remote connection opened Sending request: POST /mpeg4/media.amp HTTP/1.1 CSeq: 1 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Host: 128.197.178.101 x-sessioncookie: 11828aef671cfcf975c137d Content-Type: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Content-Length: 32767 Expires: Sun, 9 Jan 1972 00:00:00 GMT Sending request: OPTIONS rtsp://128.197.178.101/mpeg4/media.amp RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) The request was base-64 encoded to: T1BUSU9OUyBydHNwOi8vMTI4LjE5Ny4xNzguMTAxL21wZWc0L21lZGlhLmFtcCBSVFNQLzEuMA0KQ1NlcTogMg0KVXNlci1BZ2VudDogLi9vcGVuUlRTUCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTQuMDIuMDcpDQoNCg== Received 91 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Public: DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, TEARDOWN Sending request: DESCRIBE rtsp://128.197.178.101/mpeg4/media.amp RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Accept: application/sdp The request was base-64 encoded to: REVTQ1JJQkUgcnRzcDovLzEyOC4xOTcuMTc4LjEwMS9tcGVnNC9tZWRpYS5hbXAgUlRTUC8xLjANCkNTZXE6IDMNClVzZXItQWdlbnQ6IC4vb3BlblJUU1AgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDE0LjAyLjA3KQ0KQWNjZXB0OiBhcHBsaWNhdGlvbi9zZHANCg0K Received 823 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Content-Base: rtsp://128.197.178.101:554/mpeg4/media.amp/ Content-Type: application/sdp Content-Length: 684 v=0 o=- 1391790981113890 1391790981113897 IN IP4 128.197.178.101 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 b=AS:8000 t=0 0 a=control:* a=range:npt=now- a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAGCQEAAAAAAAAAAA==" m=video 0 RTP/AVP 96 b=AS:8000 a=control:trackID=1 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245; config=000001B0F5000001B5090000010000000120008C4019285820F0A21F; a=mpeg4-esid:201 Opened URL "rtsp://128.197.178.101/mpeg4/media.amp", returning a SDP description: v=0 o=- 1391790981113890 1391790981113897 IN IP4 128.197.178.101 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 b=AS:8000 t=0 0 a=control:* a=range:npt=now- a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAGCQEAAAAAAAAAAA==" m=video 0 RTP/AVP 96 b=AS:8000 a=control:trackID=1 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245; config=000001B0F5000001B5090000010000000120008C4019285820F0A21F; a=mpeg4-esid:201 Created receiver for "video/MP4V-ES" subsession (client ports 51914-51915) Sending request: SETUP rtsp://128.197.178.101:554/mpeg4/media.amp/trackID=1 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 The request was base-64 encoded to: U0VUVVAgcnRzcDovLzEyOC4xOTcuMTc4LjEwMTo1NTQvbXBlZzQvbWVkaWEuYW1wL3RyYWNrSUQ9MSBSVFNQLzEuMA0KQ1NlcTogNA0KVXNlci1BZ2VudDogLi9vcGVuUlRTUCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTQuMDIuMDcpDQpUcmFuc3BvcnQ6IFJUUC9BVlAvVENQO3VuaWNhc3Q7aW50ZXJsZWF2ZWQ9MC0xDQoNCg== Received 120 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Session: 1825287805;timeout=60 Transport: RTP/AVP/TCP;unicast;mode=play;interleaved=24-25 Setup "video/MP4V-ES" subsession (client ports 51914-51915) Created output file: "video-MP4V-ES-1" Sending request: PLAY rtsp://128.197.178.101:554/mpeg4/media.amp/ RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2014.02.07) Session: 1825287805 Range: npt=0.000- The request was base-64 encoded to: UExBWSBydHNwOi8vMTI4LjE5Ny4xNzguMTAxOjU1NC9tcGVnNC9tZWRpYS5hbXAvIFJUU1AvMS4wDQpDU2VxOiA1DQpVc2VyLUFnZW50OiAuL29wZW5SVFNQIChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxNC4wMi4wNykNClNlc3Npb246IDE4MjUyODc4MDUNClJhbmdlOiBucHQ9MC4wMDAtDQoNCg== Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Session: 1825287805 Range: npt=now- RTP-Info: url=trackID=1;seq=52465;rtptime=806046324 Started playing session Receiving streamed data (signal with "kill -HUP 93865" or "kill -USR1 93865" to terminate)... ------So, I can't explain why it's not working for you. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Feb 8 11:41:49 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Feb 2014 08:41:49 +1300 Subject: [Live-devel] Bad "Range:" header error introduced In-Reply-To: References: , , <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com>, , <2539FDB1-F5DC-4636-9820-A83C7A805CF3@live555.com> Message-ID: > This is really strange. The discrepancy was caused by the fact that you were running LIVE555 version 2014.02.04, and I was running version 2014.02.07. Please upgrade to the latest version - 2014.02.08 - which should fix this problem for real. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john95018 at gmail.com Fri Feb 7 21:20:47 2014 From: john95018 at gmail.com (john dicostanzo) Date: Sat, 8 Feb 2014 10:50:47 +0530 Subject: [Live-devel] regarding test app MPEG2TransportStreamIndexer In-Reply-To: <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> References: <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> Message-ID: HI, Thanks for your reply. Unfortunately i can't share my Transport Stream due to same confidential reason. Basically its a encrypted stream and when some one gives input this stream to Indexer, it gives error and goes down in the middle of indexing,so i want to catch this error in my application because i have to perform some action on this error On Fri, Feb 7, 2014 at 8:23 AM, Ross Finlayson wrote: > I am using test app MPEG2TransportStreamIndexer. > In file MPEG2IndexFromTransportStream.cpp,when it got error "Unexpectedly > large PES header size" its close all handles and goes down. > > > John, > > Thanks for the note. > > Please put your Transport Stream file (the one that produces this error) > on a (publically-accessible) web server, and send us the URL, so we can > download it and test it ourself. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Feb 9 09:01:42 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Feb 2014 06:01:42 +1300 Subject: [Live-devel] regarding test app MPEG2TransportStreamIndexer In-Reply-To: References: <746FCC24-7BE3-4C62-9C49-302CE53F0379@live555.com> Message-ID: <951DEEE8-7BBF-469F-B679-DA5B00E642AA@live555.com> > Unfortunately i can't share my Transport Stream due to same confidential reason. Perhaps it's the same "confidential reason" why you use an unprofessional email address :-) It's hard to debug a problem if you won't provide an example of a file that illustrates the problem. Especially since this software is being provided 'for free'. Fortunately, however, Warren Young sent me examples of some other files that have the same problem. I found that the problem (for our indexing software) with these files is that some of the (188-byte) Transport Packets have the "payload_unit_start_indicator" flag set, but the payload (after the 'adaptation field') does not begin a PES packet (i.e., does not begin with 0x00 0x00 0x01). A QUESTION FOR MPEG TRANSPORT STREAM EXPERTS: Do you know why this is happening? I.e., what are these non-PES packet payloads, if the "payload_unit_start_indicator" flag is set? (I could easily modify our indexing software to ignore payloads (when the "payload_unit_start_indicator" flag is set) that don't start with 0x00 0x00 0x01. However, I'm afraid that if I did this, I might be missing out on some legitimate PES packet headers that start elsewhere within the payload. I.e., I'd prefer to understand exactly what these non-PES packet payloads are. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbrimer at oncamgrandeye.com Mon Feb 10 02:16:28 2014 From: mbrimer at oncamgrandeye.com (Michael Brimer) Date: Mon, 10 Feb 2014 10:16:28 +0000 Subject: [Live-devel] Media level SDP lines exceed memory allocation Message-ID: Hi, I'm a new subscriber working on security cameras. I'm experiencing an RTSP server crash in the DESCRIBE phase which I have traced to the function ServerMediaSession::generateSDPDescription(). In this function, I think the sdpLength is being calculated based on the length of the session-level description. However, at the end of the function, when the media-level description lines are appended, I believe that the previous memory allocation is being exceeded. I found that the server would crash when I was returning a large media-level description due to a large "a=fmtp:96..." string. Temporarily increasing sdpLength by 400 bytes fixed the problem. When the media-level description was a smaller length, the server did not crash but I guess there was still possible data corruption occurring unless you are building in some allowance for the maximum media-level description when calculating sdpLength. Found on version 2013.11.15. I am currently upgrading to latest version but by code inspection I guess this is still likely to occur. If you need any further info, please let me know. Regards, Mike Brimer Oncam Grandeye This communication is for the exclusive use of the addressee and may contain information that is private and confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication and its attachments is strictly prohibited. If you have received this information in error please contact the sender and delete the communication from your system. Any views or opinions presented are solely those of the author and do not necessarily represent those of Oncam Grandeye unless specifically stated. This message has been scanned for malware by Websense. www.websense.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Feb 10 03:50:43 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Feb 2014 00:50:43 +1300 Subject: [Live-devel] Media level SDP lines exceed memory allocation In-Reply-To: References: Message-ID: Thanks for the note. I've just released a new version (2014.02.10) that makes this code more bullet-proof (and also uses "snprintf()" rather than "sprintf()"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nambirajan.manickam at i-velozity.com Tue Feb 11 04:36:52 2014 From: nambirajan.manickam at i-velozity.com (Nambirajan) Date: Tue, 11 Feb 2014 18:06:52 +0530 Subject: [Live-devel] Play response setting in Live555 Server In-Reply-To: <15AB1C2C-8C6A-4A5C-AB55-075000CBFBBE@live555.com> References: <004701cf1cc6$e0c5b770$a2512650$@manickam@i-velozity.com> <006001cf1cd6$2bc036b0$8340a410$@manickam@i-velozity.com> <1466CC06-04E7-4D7E-9735-26A32993C5B4@live555.com> <001401cf227a$220f3450$662d9cf0$@manickam@i-velozity.com> <4B77F37E-3312-4420-A52D-DFD8A99BA993@live555.com> <003501cf231a$44dcb2f0$ce9618d0$@manickam@i-velozity.com> <15AB1C2C-8C6A-4A5C-AB55-075000CBFBBE@live555.com> Message-ID: <009c01cf2725$f28aa740$d79ff5c0$@manickam@i-velozity.com> Hi Ross, Thanks for the update. Now the server response to the player in REW option, when we do a REW while playing a movie is getting NPT in the range header. I have a clarification. When we do a FFW at any speed, the play is working fine ( The movie ends at the proper time than the normal playtime ). Example: When we FFW in 4X speed, the whole movie is played and ends at a time approximately 1/4th of the normal play time of the movie. But I feel it is the normal play time. Not the current play time ( trick mode play time ) in the Range header. Is it OK to pass the npt to the player or current playtime to the player in the Server response. I am using the latest code of Live 555 Media Server One strange scenario I am facing, when I do the Pause of movie, the movie is paused. My player's Play button has changed to Pause display. When do the play again, the player is working. That is movie is playing. But my Play icon is still in the Pause mode, it has not updated to the Play mode. I have been checking with the previous version dated ( 2014.01.29 ) of Server code, it was working fine. Means my player was updating the Play button properly. Can you please suggest why is it happening like this. Thanks and regards, M. Nambirajan From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Saturday, February 08, 2014 2:57 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Play response setting in Live555 Server REW x -2 RTSPClientConnection[0x11fbc40]::handleRequestBytes() read 145 new bytes:PLAY rtsp://192.168.128.51:554/OzTheGreatandHD_06112013_USA_movie_5625_CC.ts RTSP/1.0 Scale: -2 CSeq: 16 Session: 70554585 Range: npt= -0 parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "", urlSuffix "OzTheGreatandHD_06112013_USA_movie_5625_CC.ts", CSeq "16", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 16 Date: Thu, Feb 06 2014 00:34:54 GMT Scale: -2.000000 Range: npt=-0.000-0.000 Thanks for the report. I've just released a new version - 2014.02.07 - of the "LIVE555 Streaming Media" code that should fix this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brilliantov at byterg.ru Tue Feb 11 05:56:14 2014 From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich) Date: Tue, 11 Feb 2014 17:56:14 +0400 Subject: [Live-devel] On-demand RTSP-server example for FramedSource Message-ID: <52FA2BFE.5050300@byterg.ru> Hello! I use live555 2014.01.29. Now I have to add on-demand mode to RTSP-server, for this I add OnDemandServerMediaSubsession subclass and inplement createNewStreamSource, return H264VideoStreamDiscreteFramer, and createNewRTPSink, return H264VideoRTPSink, functions. When I try connect to RTSP-server I see PLAY command and after this programm exit with "Segmentation fault". This is very strange because this code work fine with multicast stream. Where can I found example for on-demand RTSP-server mode, unfortunally live555 test programm write for stream file? Thank you and excuse me for my bad english. -- Best regards, Brilliantov Kirill Vladimirovich From finlayson at live555.com Tue Feb 11 10:20:19 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Feb 2014 07:20:19 +1300 Subject: [Live-devel] Play response setting in Live555 Server In-Reply-To: <009c01cf2725$f28aa740$d79ff5c0$@manickam@i-velozity.com> References: <004701cf1cc6$e0c5b770$a2512650$@manickam@i-velozity.com> <006001cf1cd6$2bc036b0$8340a410$@manickam@i-velozity.com> <1466CC06-04E7-4D7E-9735-26A32993C5B4@live555.com> <001401cf227a$220f3450$662d9cf0$@manickam@i-velozity.com> <4B77F37E-3312-4420-A52D-DFD8A99BA993@live555.com> <003501cf231a$44dcb2f0$ce9618d0$@manickam@i-velozity.com> <15AB1C2C-8C6A-4A5C-AB55-075000CBFBBE@live555.com> <009c01cf2725$f28aa740$d79ff5c0$@manickam@i-velozity.com> Message-ID: <7B5DFADB-E104-4D8A-8855-D3A46EE29B64@live555.com> > One strange scenario I am facing, when I do the Pause of movie, the movie is paused. My player?s Play button has changed to Pause display. When do the play again, the player is working. That is movie is playing. But my Play icon is still in the Pause mode, it has not updated to the Play mode. > > I have been checking with the previous version dated ( 2014.01.29 ) of Server code, it was working fine. Means my player was updating the Play button properly. Can you please suggest why is it happening like this. No I can't, because your "media player" is not our software. The only thing I can help you with is problems with the RTSP *protocol* - which is what our software implements. I.e., if you can show us a specific RTSP request and response that was was working one way before, and a different way now. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Feb 11 10:34:09 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Feb 2014 07:34:09 +1300 Subject: [Live-devel] On-demand RTSP-server example for FramedSource In-Reply-To: <52FA2BFE.5050300@byterg.ru> References: <52FA2BFE.5050300@byterg.ru> Message-ID: > Now I have to add on-demand mode to RTSP-server, for this I add > OnDemandServerMediaSubsession subclass and inplement > createNewStreamSource, return H264VideoStreamDiscreteFramer, and > createNewRTPSink, return H264VideoRTPSink, functions. > When I try connect to RTSP-server I see PLAY command and after this > programm exit with "Segmentation fault". Your first task - before posting to this mailing list - is to find out exactly where in the code this "segmentation fault" is occurring, and why. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbrimer at oncamgrandeye.com Wed Feb 12 01:46:16 2014 From: mbrimer at oncamgrandeye.com (Michael Brimer) Date: Wed, 12 Feb 2014 09:46:16 +0000 Subject: [Live-devel] Media level SDP lines exceed memory allocation In-Reply-To: References: Message-ID: Thanks Ross. Tested and working in 2014.02.10. Mike From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 10 February 2014 11:51 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Media level SDP lines exceed memory allocation Thanks for the note. I've just released a new version (2014.02.10) that makes this code more bullet-proof (and also uses "snprintf()" rather than "sprintf()"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ Click here to report this email as spam. This message has been scanned for malware by Websense. www.websense.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ksilver986 at gmail.com Wed Feb 12 01:54:55 2014 From: ksilver986 at gmail.com (Kevin Silver) Date: Wed, 12 Feb 2014 09:54:55 +0000 Subject: [Live-devel] Stream WAV audio over RTP In-Reply-To: <6C3E8D7E-C317-4D05-A787-36A9601588EC@live555.com> References: <6C3E8D7E-C317-4D05-A787-36A9601588EC@live555.com> Message-ID: Ross, Thank you very much for this. Exactly the information I required. I have written a SAP implementation and this is now working well for my needs. Thank you for your help Kevin On 7 February 2014 02:52, Ross Finlayson wrote: > I am writing an application which I would like to stream 8 and 16 bit pcm > audio from wav files over rtp to a receiver elsewhere on my network. The > control mechanism for this however will eventually be snmp (with SAP > messages for the reciever configuration) rather than rtcp so I would like > the stream to simply be rtp. > > I have seen the example program 'testWAVAudioStreamer' which is clearly > very close to my needs however using rtsp. > > I was wondering whether there is an example available to use the libraries > to send out rtp without the control protocol? > > > Kevin, > > Sorry for the delay in responding. > > Because the "test*Streamer" applications (including > "testWAVAudioStreamer") transmit using IP multicast rather than IP unicast, > receiving applications *do not* need to use RTSP. RTSP just happens to be > a convenient way for a receiving application to get the stream's SDP > description. (This is especially true for "testWAVAudioStreamer", because > the SDP description depends upon the properties of the particular WAV audio > file that it's streaming. > > But there's no reason why the multicast streaming application (e.g., > "testWAVAudioStreamer") can't make the SDP description available some other > way - e.g., via SAP. To do this, add the following code at line 214 of > "testProgs/testWAVAudioStreamer.cpp": > > char* ourSDPDescription = sms->generateSDPDescription(); > > This will give you a SDP description string that you can announce using > SAP. (We don't provide code for SAP announcing; you'd have to write that > yourself.) > > > 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 ELIMCO.dmartinez at navantia.es Thu Feb 13 00:19:23 2014 From: ELIMCO.dmartinez at navantia.es (=?iso-8859-1?Q?Mart=EDnez_Contador=2C_Daniel_=5BELIMCO=5D_=28CA=29?=) Date: Thu, 13 Feb 2014 08:19:23 +0000 Subject: [Live-devel] Concerning multicast TTL of zero Message-ID: Hello. For my application I need to send differently scoped multicast RTP. I have found that I use both the multicast address and the TTL to try different configurations. However, I cannot send multicast packets with a TTL of zero (meaning traffic restricted to the same host). They get sent but with a TTL of 1 (meaning traffic restricted to the same subnet, not what I want). I have seen the problem lies in writeSocket in GroupsockHelper: it skips the setsockopt to set the TTL if it is 0. Removing the condition seems to work (meaning such packets reach receivers in the same host but are not seen by other hosts in the subnet or traffic analysers), but I wonder if not setting TTL 0 is intentional and by enabling it I will be having "collaterals". So, should everything work as expected when enabling TTL 0? Would this be filed as a "bug" and be corrected in the next version? I could send a patch, but that would make me a "contributor" and for just removing two obvious lines seems to much of a mention. Best Regards. Daniel Mart?nez Contador Navantia - Sistemas de Control Ctra. Algameca, s/n 30205 Cartagena (Murcia) Tlfo: 968 323 387 Email: elimco.dmartinez at navantia.es NAVANTIA ______________________________ Este mensaje, y cualquier fichero anexo al mismo, contiene informacion de caracter confidencial dirigida exclusivamente a su(s) destinatario(s) y, en su caso, sometida a secreto profesional. Queda prohibida su difusion, copia o distribucion a terceros sin la previa autorizacion escrita. Si Vd. ha recibido este mensaje por error, se ruega lo comunique inmediatamente por esta misma via y proceda a su completa eliminacion. The information in this e-mail, and in any attachments, is confidential and, if any, protected by a professional privilege, and intended solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, copy or distribution of this information is prohibited without the prior written consent. If you have received this communication in error, please notify the sender by reply e-mail and delete it. ______________________________ From finlayson at live555.com Thu Feb 13 00:45:32 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Feb 2014 21:45:32 +1300 Subject: [Live-devel] Concerning multicast TTL of zero In-Reply-To: References: Message-ID: <3A6F7A44-0EAC-4BEC-8EC8-366EC95B6876@live555.com> > For my application I need to send differently scoped multicast RTP. > I have found that I use both the multicast address and the TTL to try different configurations. > However, I cannot send multicast packets with a TTL of zero (meaning traffic restricted to the same host). They get sent but with a TTL of 1 (meaning traffic restricted to the same subnet, not what I want). > I have seen the problem lies in writeSocket in GroupsockHelper: it skips the setsockopt to set the TTL if it is 0. > Removing the condition seems to work (meaning such packets reach receivers in the same host but are not seen by other hosts in the subnet or traffic analysers), but I wonder if not setting TTL 0 is intentional and by enabling it I will be having "collaterals". > So, should everything work as expected when enabling TTL 0? > Would this be filed as a "bug" and be corrected in the next version? Yes, probably. Thanks for the note. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eli.b at BDRGroup.com Thu Feb 13 06:13:45 2014 From: eli.b at BDRGroup.com (Eli) Date: Thu, 13 Feb 2014 14:13:45 +0000 Subject: [Live-devel] RTP H.264 stream freezing on first frame using wis-streamer and VLC player Message-ID: <6417F92C89FF5A4FA32A8F56070CA740020934E2@QUEEN.BDRGroup.local> Hi everyone, I have encountered a strange problem while playing an RTP H.264 stream using VLC player. I am developing firmware for an IP camera designed to be used with specialized software (control client). By default, the camera's RTSP streamer (based on wis-streamer with a custom video source) had a bug where in each GOP, the SPS, PPS, SEI and IDR-frame were all grouped, and the stream simply consisted of an SPS NAL unit, followed by several P-slices. The PPS, SEI, and IDR-frame were all hidden inside the payload of the SPS packet. This caused the target software to be unable to play the stream, yet VLC player worked just fine. After fixing the video source and properly splitting the various NAL units, the stream works properly on the target client, but now it works only partially with VLC - sometimes it works well, other times it freezes after showing 1-2 frames. Looking at the wireshark capture, the stream now looks like a proper H.264 stream: SPS, PPS, SEI, IDR, P-Slice, P-Slice, P-Slice... I've uploaded wireshark logs and VLC logs for both scenarios (old stream, new stream): https://www.dropbox.com/s/kk4m04toudijb82/new.log https://www.dropbox.com/s/gyg39osmhqi7p1r/New.pcapng https://www.dropbox.com/s/ewank7m3itt8jcr/old.log https://www.dropbox.com/s/jk08a4nq8cuog76/Old.pcapng I've posted this question to the VLC support boards and was advised it might be a live555 problem and that I should ask about it over here. Any help would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Feb 13 07:43:07 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Feb 2014 04:43:07 +1300 Subject: [Live-devel] RTP H.264 stream freezing on first frame using wis-streamer and VLC player In-Reply-To: <6417F92C89FF5A4FA32A8F56070CA740020934E2@QUEEN.BDRGroup.local> References: <6417F92C89FF5A4FA32A8F56070CA740020934E2@QUEEN.BDRGroup.local> Message-ID: Sorry, but we can't help you with 'decoding'/'freezing' problems with VLC, because VLC is not our software. (We provide only the implementation of the RTSP client protocol that VLC uses.) I suggest instead that you start by using our "openRTSP" client application to receive your stream (it will write the received H.264 video data into a file). Then, rename this file to have a ".h264" filename suffix, and try playing this file with VLC. If VLC has the same 'decoding'/'freezing' problems when it plays the received file, then the problem must be with your encoder and/or VLC; it has nothing to do with us. If, however, VLC plays the received file OK, then there might, conceivably, be some problem with the 'presentation times' that your server gives to each NAL unit that it sends. You could test this by running our "testRTSPClient" demo application. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Thu Feb 13 08:00:28 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Thu, 13 Feb 2014 11:00:28 -0500 Subject: [Live-devel] RTP H.264 stream freezing on first frame using wis-streamer and VLC player In-Reply-To: <6417F92C89FF5A4FA32A8F56070CA740020934E2@QUEEN.BDRGroup.local> References: <6417F92C89FF5A4FA32A8F56070CA740020934E2@QUEEN.BDRGroup.local> Message-ID: Sounds like you have a good understanding of the nal units and h264 traffic in general. So It might be a decoder issue. I have found descrepencies in interpretations of the standard. >From experience... Each Nal unit needs a header before it goes to the decoder. This is the 00 00 00 01 before the nal unit. I have seen some streams only have 00 00 01 and different versions of libavcodec for example would be tolerent or not tolerent of this. Assuming [x] represents the nal unit x with the headers. and 7 is sps 8 is pps 5 is IDR slice and 1 is P-slice [7][8][5][1][1][1]...[1][7][8][5][1][1]... is normal [7][8][5][5][5][1][1][1]...[1][7][8][5][5][5][1][1]... is seen on high resolution [7][8][5][1][1][1]...[1][5][1][1]... is legal [7][8][5][1][1][1]...[1][7][8][1][1]...[5][1][1].... is actually legal per standard but messes with some decoders. On Thu, Feb 13, 2014 at 9:13 AM, Eli wrote: > Hi everyone, > > > > I have encountered a strange problem while playing an RTP H.264 stream > using VLC player. > > > > I am developing firmware for an IP camera designed to be used with > specialized software (control client). > > By default, the camera's RTSP streamer (based on wis-streamer with a > custom video source) had a bug where in each GOP, the SPS, PPS, SEI and > IDR-frame were all grouped, and the stream simply consisted of an SPS NAL > unit, followed by several P-slices. The PPS, SEI, and IDR-frame were all > hidden inside the payload of the SPS packet. This caused the target > software to be unable to play the stream, yet VLC player worked just fine. > > > > After fixing the video source and properly splitting the various NAL > units, the stream works properly on the target client, but now it works > only partially with VLC - sometimes it works well, other times it freezes > after showing 1-2 frames. Looking at the wireshark capture, the stream now > looks like a proper H.264 stream: SPS, PPS, SEI, IDR, P-Slice, P-Slice, > P-Slice... > > I've uploaded wireshark logs and VLC logs for both scenarios (old stream, > new stream): > > > > https://www.dropbox.com/s/kk4m04toudijb82/new.log > > https://www.dropbox.com/s/gyg39osmhqi7p1r/New.pcapng > > > > https://www.dropbox.com/s/ewank7m3itt8jcr/old.log > > https://www.dropbox.com/s/jk08a4nq8cuog76/Old.pcapng > > > I've posted this question to the VLC support boards and was advised it > might be a live555 problem and that I should ask about it over here. > > Any help would be greatly appreciated. > > _______________________________________________ > 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 jkordani at lsa2.com Thu Feb 13 12:51:19 2014 From: jkordani at lsa2.com (Joshua Kordani) Date: Thu, 13 Feb 2014 15:51:19 -0500 Subject: [Live-devel] RTP H.264 stream freezing on first frame using wis-streamer and VLC player Message-ID: 4 byte start code is required on sps and pps nals. All others may be 3 or 4 bytes. Admittedly, the spec is way too wordy but is summarized in the previous sentence. Also, the pps and sps nals do not need to be repeated unless the future frame requires it. I have a camera that only supplies sps and pps in the rtsp setup, and then emits idr and slice in the rtp stream Jeff Shanab wrote: >_______________________________________________ >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 demthedj at gmail.com Tue Feb 11 22:37:13 2014 From: demthedj at gmail.com (Sergey Kuprienko) Date: Wed, 12 Feb 2014 08:37:13 +0200 Subject: [Live-devel] RTCPInstance::onExpire do not unscheduled from desctructor Message-ID: I'm using several RTSP clients threads in my app. Occasionaly in test environment, when RTSP servers are frequently restarted, i'm catching SIGSEGV here : ~"#0 RTCPInstance::numMembers (this=0x7fffaca5e6e0) at RTCP.cpp:234\n" >~"#1 0x00007ffff6246823 in RTCPInstance::onExpire1 (this=0x7fffaca5e6e0) at RTCP.cpp:926\n" >~"#2 0x00007ffff6246873 in RTCPInstance::onExpire (instance=) at RTCP.cpp:694\n" >~"#3 0x00007ffff624417b in AlarmHandler::handleTimeout (this=0x7fffac9437e0) at BasicTaskScheduler0.cpp:34\n" >~"#4 0x00007ffff62445e2 in DelayQueue::handleAlarm (this=0x7fffac001d28) at DelayQueue.cpp:187\n" >~"#5 0x00007ffff6242f8a in CPollTaskScheduler::SingleStep (this=0x7fffac001d20, maxDelayTime=) at cpolltaskscheduler.cpp:204\n" >~"#6 0x00007ffff6243b95 in BasicTaskScheduler0::doEventLoop (this=0x7fffac001d20, watchVariable=0xc73200 \"\") at BasicTaskScheduler0.cpp:80\n" >~"#7 0x00007ffff6242376 in CRTSPv2ClientThread::run (this=0xc73100) at crtspv2clientthread.cpp:223\n" I made some debugging and believe "this" is invalid at RTCPInstance::numMembers. It seems RTCPInstance was destroyed due to closing subsessions, but unshedule() of onExpire() was not performed. What are the conditions that may lead to that ? ps. I use several - up to 4 - RTSP clients per single TaskScheduler + dedicated UsageEnvironment. -- ?????? ????????? ????? ?????????? ??, "??-??" Sergey Kuprienko Head of software development dpt. http://www.f-f.kiev.ua +38 097 985 15 69 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Doug.Jones at rsa.rohde-schwarz.com Fri Feb 14 18:57:51 2014 From: Doug.Jones at rsa.rohde-schwarz.com (Doug.Jones at rsa.rohde-schwarz.com) Date: Fri, 14 Feb 2014 20:57:51 -0600 Subject: [Live-devel] Compiling live.2014.2.13 in Windows Message-ID: I have Visual Studio 2012 and have follwed the directions at https://github.com/iSECPartners/RtspFuzzer/wiki/Compiling-OpenRtsp-with-VS-2012 and at http://blog.mmone.de/2013/06/building-the-live555-streaming-media-framwork-on-windows-with-visual-studio-2012/ using the live.2014.02.13.tar.gz source. I cannot get either testProgs or mediaServer to build. I get the following: H:\Visual Studio 2012\Projects\live555\live\mediaServer>nmake /B -f mediaServer.mak Microsoft (R) Program Maintenance Utility Version 11.00.60610.1 Copyright (C) Microsoft Corporation. All rights reserved. C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\link -out:live555MediaServer.exe /RELEASE msvcrt.lib /INCREMENTA L:NO /NOLOGO -subsystem:console,5.0 kernel32.lib ws2_32.lib mswsock.lib advapi32.lib live555MediaServer.obj DynamicRTSPServer.obj . ./liveMedia/libliveMedia.lib ../groupsock/libgroupsock.lib ../BasicUsageEnvironment/libBasicUsageEnvironment.lib ../UsageEnvironmen t/libUsageEnvironment.lib 'C:\Program' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'C:\Program' : return code '0x1' Stop. I know this is probably not a problem with the source but I'll be darned if I can figure out what the problem is. Thanks for your help. Best Regards, Doug Douglas R. Jones Sr. Software Engineer/Project Manager Rohde & Schwarz USA, Inc. 1500 Lakeside Pkwy., Suite 100 Flower Mound, TX. 75028 Mobile: +1 214-601-3301 Office: +1 469-713-5344 E-Mail: Doug.Jones at rsa.rohde-schwarz.com Website: http://www.rohde-schwarz.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 8360 bytes Desc: not available URL: From finlayson at live555.com Sat Feb 15 02:33:06 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 15 Feb 2014 23:33:06 +1300 Subject: [Live-devel] Compiling live.2014.2.13 in Windows In-Reply-To: References: Message-ID: > I have Visual Studio 2012 and have follwed the directions at https://github.com/iSECPartners/RtspFuzzer/wiki/Compiling-OpenRtsp-with-VS-2012 and at http://blog.mmone.de/2013/06/building-the-live555-streaming-media-framwork-on-windows-with-visual-studio-2012/ I don't know what prompted you to visit those web pages; they have nothing to do with us. Your starting point should be http://www.live555.com/liveMedia/#config-windows But, in any case, your problem is simple: > C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\link -out:live555MediaServer.exe /RELEASE msvcrt.lib /INCREMENTA > L:NO /NOLOGO -subsystem:console,5.0 kernel32.lib ws2_32.lib mswsock.lib advapi32.lib live555MediaServer.obj DynamicRTSPServer.obj . > ./liveMedia/libliveMedia.lib ../groupsock/libgroupsock.lib ../BasicUsageEnvironment/libBasicUsageEnvironment.lib ../UsageEnvironmen > t/libUsageEnvironment.lib > 'C:\Program' is not recognized as an internal or external command There need to be quotes (either "" or ''; I'm not sure) around "Program Files (x86)" (and also "Microsoft Visual Studio 11.0"); otherwise Windoze thinks that the command is "C:\Program". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Doug.Jones at rsa.rohde-schwarz.com Sat Feb 15 10:43:32 2014 From: Doug.Jones at rsa.rohde-schwarz.com (Doug.Jones at rsa.rohde-schwarz.com) Date: Sat, 15 Feb 2014 12:43:32 -0600 Subject: [Live-devel] Compiling live.2014.2.13 in Windows In-Reply-To: References: Message-ID: Ross, Thanks. The answer to the question is a combination of Google and not finding much at the #config-windows section of the web site. I have been doing managed code for a while now and am rusty on my unmanaged code in WinDoze. A little beef up of this section would be helpful. Be happy to contribute if you take contributions. So that leads me to a couple of questions. Can I do the compiles from within the Visual Studio 2012 IDE? I have only done C# from within the IDE. Also is there a WPF control or information on how to use live555 from within WPF? My problem is really simple to describe but is proving to be a bit tougher to solve. I have a WPF app that I need to display a H.264 stream from a RTSP address at 30FPS 1920 x 1080 and scale that to fit (or use scroll bars). I do not want to manipulate the stream just display it. Suggestions? Any and all would be highly appreciated! Best Regards, Doug Douglas R. Jones Sr. Software Engineer/Project Manager Rohde & Schwarz USA, Inc. 1500 Lakeside Pkwy., Suite 100 Flower Mound, TX. 75028 Mobile: +1 214-601-3301 Office: +1 469-713-5344 E-Mail: Doug.Jones at rsa.rohde-schwarz.com Website: http://www.rohde-schwarz.com/ From: Ross Finlayson To: LIVE555 Streaming Media - development & use , Date: 02/15/2014 04:40 Subject: Re: [Live-devel] Compiling live.2014.2.13 in Windows Sent by: live-devel-bounces at ns.live555.com I have Visual Studio 2012 and have follwed the directions at https://github.com/iSECPartners/RtspFuzzer/wiki/Compiling-OpenRtsp-with-VS-2012 and at http://blog.mmone.de/2013/06/building-the-live555-streaming-media-framwork-on-windows-with-visual-studio-2012/ I don't know what prompted you to visit those web pages; they have nothing to do with us. Your starting point should be http://www.live555.com/liveMedia/#config-windows But, in any case, your problem is simple: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\link -out:live555MediaServer.exe /RELEASE msvcrt.lib /INCREMENTA L:NO /NOLOGO -subsystem:console,5.0 kernel32.lib ws2_32.lib mswsock.lib advapi32.lib live555MediaServer.obj DynamicRTSPServer.obj . ./liveMedia/libliveMedia.lib ../groupsock/libgroupsock.lib ../BasicUsageEnvironment/libBasicUsageEnvironment.lib ../UsageEnvironmen t/libUsageEnvironment.lib 'C:\Program' is not recognized as an internal or external command There need to be quotes (either "" or ''; I'm not sure) around "Program Files (x86)" (and also "Microsoft Visual Studio 11.0"); otherwise Windoze thinks that the command is "C:\Program". 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 8360 bytes Desc: not available URL: From Doug.Jones at rsa.rohde-schwarz.com Sat Feb 15 11:53:32 2014 From: Doug.Jones at rsa.rohde-schwarz.com (Doug.Jones at rsa.rohde-schwarz.com) Date: Sat, 15 Feb 2014 14:53:32 -0500 Subject: [Live-devel] Compiling live.2014.2.13 in Windows In-Reply-To: Message-ID: <456FB681-DF19-44E7-854C-7BEE0CBF3E63@rsa.rohde-schwarz.com> Ross, Seems that my compile problem was related to the make file. Not sure what but copying over the section from a working make file. Now testProgs and the other make file that links to exe files is now giving me a similar complaint. Not sure why? Thanks, Doug Sent from my iPhone On Feb 15, 2014, at 5:40, "Ross Finlayson" wrote: I have Visual Studio 2012 and have follwed the directions at https://github.com/iSECPartners/RtspFuzzer/wiki/Compiling-OpenRtsp-with-VS-2012 and at http://blog.mmone.de/2013/06/building-the-live555-streaming-media-framwork-on-windows-with-visual-studio-2012/ I don't know what prompted you to visit those web pages; they have nothing to do with us. ?Your starting point should be http://www.live555.com/liveMedia/#config-windows But, in any case, your problem is simple: ? ? ? ? C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\link -out:live555MediaServer.exe /RELEASE msvcrt.lib ?/INCREMENTA L:NO /NOLOGO -subsystem:console,5.0 kernel32.lib ?ws2_32.lib mswsock.lib advapi32.lib live555MediaServer.obj DynamicRTSPServer.obj . ./liveMedia/libliveMedia.lib ../groupsock/libgroupsock.lib ../BasicUsageEnvironment/libBasicUsageEnvironment.lib ../UsageEnvironmen t/libUsageEnvironment.lib 'C:\Program' is not recognized as an internal or external command There need to be quotes (either "" or ''; I'm not sure) around "Program Files (x86)" (and also "Microsoft Visual Studio 11.0"); otherwise Windoze thinks that the command is "C:\Program". Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing listlive-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From brilliantov at byterg.ru Wed Feb 12 04:09:25 2014 From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich) Date: Wed, 12 Feb 2014 16:09:25 +0400 Subject: [Live-devel] Segmentation fault in FramedSource::getNextFrame Message-ID: <52FB6475.3020108@byterg.ru> Hello! I use live555 2014.01.29. For run on-demand RTSP-server I write OnDemandServerMediaSubsession subclass with implements createNewStreamSource, return H264VideoStreamDiscreteFramer, and createNewRTPSink, return H264VideoRTPSink. Unfortunally programm exit with "Segmentation fault" after PLAY command. OpenRTSP log: .......... Received 216 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Thu, Jan 01 1970 01:18:14 GMT Transport: RTP/AVP;unicast;destination=192.168.255.1;source=192.168.255.2;client_port=37662-37663;server_port=6970-6971 Session: B671D2F8;timeout=65 Setup "video/H264" subsession (client ports 37662-37663) Created output file: "video-H264-1" Sending request: PLAY rtsp://192.168.255.2/0/ RTSP/1.0 CSeq: 5 User-Agent: openRTSP (LIVE555 Streaming Media v2012.05.17) Session: B671D2F8 Range: npt=0.000- GDB output: Breakpoint 1, FramedSource::getNextFrame (this=0x54ba4b70, to=0x2be8d21c "tW\256ThK\272ThK\272Th\352", maxSize=1421257168, afterGettingFunc=0x54b91738, afterGettingClientData=0x54bbe940, onCloseFunc=0x54ae5774 , onCloseClientData=0x54bbe940) at FramedSource.cpp:64 64 in FramedSource.cpp (gdb) s 61 in FramedSource.cpp (gdb) 63 in FramedSource.cpp (gdb) 64 in FramedSource.cpp (gdb) print fIsCurrentlyAwaitingData $1 = 128 '\200' (gdb) s Medium::envir (this=0x54b9a638) at /home/kirill/Projects/MobileCam/src/live/liveMedia/include/Media.hh:59 59 /home/kirill/Projects/MobileCam/src/live/liveMedia/include/Media.hh: No such file or directory. (gdb) Program received signal SIGSEGV, Segmentation fault. 0x54ae55ac in FramedSource::getNextFrame (this=0x54b9a638, to=0x54f5bef1 "", maxSize=60000, afterGettingFunc=0x54b32194 , afterGettingClientData=0x54bbe940, onCloseFunc=0x54ae5774 , onCloseClientData=0x54bbe940) at FramedSource.cpp:64 64 FramedSource.cpp: No such file or directory. (gdb) bt #0 0x54ae55ac in FramedSource::getNextFrame (this=0x54b9a638, to=0x54f5bef1 "", maxSize=60000, afterGettingFunc=0x54b32194 , afterGettingClientData=0x54bbe940, onCloseFunc=0x54ae5774 , onCloseClientData=0x54bbe940) at FramedSource.cpp:64 #1 0x54b3217c in H264or5VideoStreamDiscreteFramer::doGetNextFrame ( this=0x54bbe940) at H264or5VideoStreamDiscreteFramer.cpp:40 #2 0x54ae56c8 in FramedSource::getNextFrame (this=0x54bbe940, to=0x54f5bef1 "", maxSize=60000, afterGettingFunc=0x54b46108 , afterGettingClientData=0x54ba4b68, onCloseFunc=0x54ae5774 , onCloseClientData=0x54ba4b68) at FramedSource.cpp:78 #3 0x54b45bf8 in H264or5Fragmenter::doGetNextFrame (this=0x54ba4b68) at H264or5VideoRTPSink.cpp:180 #4 0x54ae56c8 in FramedSource::getNextFrame (this=0x54ba4b68, to=0x54bac1f4 "\340\301\272T \304\362z\352\346UK\306SzG\037\262\364A\277Q\304\202 `\272n\036h\301\360\206t\243p\030\230\212\023\204\352I;\370\233\b\254\016v\241\223\206\f\016\254D%\204\316\065%\220\262\230\205\v\344\231J\360\b\226\r#\343)\320\201\277\230\020\rs\tX\215F\363\240\266\210\032,\\]\336E\bH\332H\366\236?\025\243U\230\353n;\027\027\204\247\004\001W\221\310\270\213L\247\261e\210\362\310\351\006\206\207oN9\227v\220\261\021r\021>ic\232x\231F\034\354\224", maxSize=60804, afterGettingFunc=0x54af6f3c , afterGettingClientData=0x54e3cae8, onCloseFunc=0x54af7ae0 , onCloseClientData=0x54e3cae8) at FramedSource.cpp:78 #5 0x54af6f1c in MultiFramedRTPSink::packFrame (this=0x54e3cae8) at MultiFramedRTPSink.cpp:216 #6 0x54af6d5c in MultiFramedRTPSink::buildAndSendPacket (this=0x54e3cae8, isFirstPacket=1 '\001') at MultiFramedRTPSink.cpp:191 #7 0x54af6ba4 in MultiFramedRTPSink::continuePlaying (this=0x54e3cae8) at MultiFramedRTPSink.cpp:152 #8 0x54b455e4 in H264or5VideoRTPSink::continuePlaying (this=0x54e3cae8) at H264or5VideoRTPSink.cpp:125 #9 0x54aeb170 in MediaSink::startPlaying (this=0x54e3cae8, source=..., afterFunc=0x54b2321c , afterClientData=0x54e3ccf0) at MediaSink.cpp:78 #10 0x54b238f0 in StreamState::startPlaying (this=0x54e3ccf0, dests=0x54e3cd30, rtcpRRHandler= 0x54b081e0 , rtcpRRHandlerClientData=0x54bbeab8, serverRequestAlternativeByteHandler=0x54b029f8 , serverRequestAlternativeByteHandlerClientData=0x54ef6690) at OnDemandServerMediaSubsession.cpp:491 #11 0x54b22648 in OnDemandServerMediaSubsession::startStream ( this=0x54ba43c0, clientSessionId=3786496502, streamToken=0x54e3ccf0, rtcpRRHandler=0x54b081e0 , rtcpRRHandlerClientData=0x54bbeab8, rtpSeqNum=@0x2be8d42e: 0, rtpTimestamp=@0x2be8d428: 0, serverRequestAlternativeByteHandler=0x54b029f8 , serverRequestAlternativeByteHandlerClientData=0x54ef6690) at OnDemandServerMediaSubsession.cpp:203 #12 0x54b07bb4 in RTSPServer::RTSPClientSession::handleCmd_PLAY ( this=0x54bbeab8, ourClientConnection=0x54ef6690, subsession=0x0, fullRequestStr=0x54ef66b4 "PLAY rtsp://192.168.255.2/0/ RTSP/1.0\r\nCSeq: 5\r\nUser-Agent: openRTSP (LIVE555 Streaming Media v2012.05.17)\r\nSession: E1B159F6\r\nRange: npt=0.000-\r\n\r\n") at RTSPServer.cpp:1984 #13 0x54b06bd8 in RTSPServer::RTSPClientSession::handleCmd_withinSession ( this=0x54bbeab8, ourClientConnection=0x54ef6690, cmdName=0x2be8d9e8 "PLAY", urlPreSuffix=0x2be8d920 "0", urlSuffix=0x2be8d858 "", fullRequestStr=0x54ef66b4 "PLAY rtsp://192.168.255.2/0/ RTSP/1.0\r\nCSeq: 5\r\nUser-Agent: openRTSP (LIVE555 Streaming Media v2012.05.17)\r\nSession: E1B159F6\r\nRange: npt=0.000-\r\n\r\n") at RTSPServer.cpp:1785 #14 0x54b038e4 in RTSPServer::RTSPClientConnection::handleRequestBytes ( this=0x54ef6690, newBytesRead=148) at RTSPServer.cpp:1014 #15 0x54b029e4 in RTSPServer::RTSPClientConnection::incomingRequestHandler1 ( this=0x54ef6690) at RTSPServer.cpp:787 #16 0x54b02970 in RTSPServer::RTSPClientConnection::incomingRequestHandler ( instance=0x54ef6690) at RTSPServer.cpp:780 ---Type to continue, or q to quit--- #17 0x54b64e58 in BasicTaskScheduler::SingleStep (this=0x54b9a370, maxDelayTime=0) at BasicTaskScheduler.cpp:163 #18 0x54b68f44 in BasicTaskScheduler0::doEventLoop (this=0x54b9a370, watchVariable=0x54b96cfb "") at BasicTaskScheduler0.cpp:80 #19 0x54ad9eac in stream_thread (arg=0x7ef91ccc) at src/stream_thread.cpp:118 #20 0x2ae7580c in ?? () from /lib/libpthread.so.0 How can I solve this problem? Thank you and excuse me for my bad english. -- Best regards, Brilliantov Kirill Vladimirovich From kcchao0921 at gmail.com Wed Feb 12 23:52:43 2014 From: kcchao0921 at gmail.com (=?UTF-8?B?6LaZ5ZyL56ug?=) Date: Thu, 13 Feb 2014 15:52:43 +0800 Subject: [Live-devel] Fwd: Destructor of SocketDescriptor seems do things wrong. In-Reply-To: References: Message-ID: Hi Ross, I use liveMedia library 2014.01.24 to do streaming via RTSP over TCP. When client is still connecting to server and I delete RTSPServer, my system will crash. The following is the call stack I traced: == RTSPServer.cpp RTSPServer::~RTSPServer (line 309) -> RTSPClientSession::~RTSPClientSession -> RTSPClientSession::reclaimStreamStates == OnDemandServerMediaSubsession.cpp -> OnDemandServerMediaSubsession::deleteStream -> StreamState::endPlaying == RTPInterface.cpp -> RTPInterface::removeStreamSocket (fRTPSink or fRTCPInstance called) -> deregisterSocket -> SocketDescriptor::deregisterRTPInterface ->SocketDescriptor::~SocketDescriptor two things happend: 1. RTPInterface::removeStreamSocket is called and it seems lead to recursive and double delete SocketDescriptor. 2. Callback fServerRequestAlternativeByteHandler is called. Now It is RTSPClientConnection::handleAlternativeRequestByte (line 1933) and call RTSPClientConnection::handleAlternativeRequestByte1 of one RTSPClientConnection instance. But all RTSPClientConnection objects have been deleted before deleting RTSPClientSession in RTSPServer::~RTSPServer. Here is my solution: 1. Just comment the code that handling remove stream socket. 2. Switch the handling order of RTSPClientConnection and RTSPClientSession. It means to delete RTSPClientSession first because RTSPClientSession is based on RTSPClientConnection. I think this is better. Don't describe very well, hope you can understand :) . Many thanks. -- ??????? ??????? ??????? ??????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eli.b at BDRGroup.com Mon Feb 17 05:37:16 2014 From: eli.b at BDRGroup.com (Eli) Date: Mon, 17 Feb 2014 13:37:16 +0000 Subject: [Live-devel] RTP H.264 stream freezing on first frame using wis-streamer and VLC player Message-ID: <6417F92C89FF5A4FA32A8F56070CA74002096AA7@QUEEN.BDRGroup.local> Thanks everyone for your replies. My camera's H264 stream looks like the following: [7] [8] [6] [5] [1] [1] [1] [1].... Obviously I remove the NAL unit headers (00 00 00 01) before passing them on to H264VideoStreamDiscreteFramer (as required) I've tried removing the SEI NAL unit [6] from the stream, this causes the stream to work for about 10 seconds and VLC stopping playback afterwards Here's the log: https://www.dropbox.com/s/6c5gv6txkmq1120/no%20sei.log I've tried following Ross Finlayson's advice and using openRTSP to record the stream into a file and play it back. VLC player couldn't recognize the file type even after renaming it to .264 I've looked at it with a hex editor and the NAL unit headers seem intact. I've tried doing the same with a different camera I have. This camera's RTSP stream works perfectly with both the target software, and VLC player I've tried to record its stream using openRTSP and play it back with VLC player without success as well. Is there anything else I could try regarding this issue? From finlayson at live555.com Mon Feb 17 09:06:04 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Feb 2014 06:06:04 +1300 Subject: [Live-devel] RTP H.264 stream freezing on first frame using wis-streamer and VLC player In-Reply-To: <6417F92C89FF5A4FA32A8F56070CA74002096AA7@QUEEN.BDRGroup.local> References: <6417F92C89FF5A4FA32A8F56070CA74002096AA7@QUEEN.BDRGroup.local> Message-ID: > I've tried following Ross Finlayson's advice and using openRTSP to record the stream into a file and play it back. VLC player couldn't recognize the file type even after renaming it to .264 You need to rename it to have a ".h264" filename suffix - as I said in my email response - not ".264". VLC doesn't recognize the ".264" filename suffix. (I've asked the VLC developers to update VLC to recognize the ".264" suffix, and treat it just like ".h264", but for some reason they don't want to do that.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eli.b at BDRGroup.com Tue Feb 18 00:51:19 2014 From: eli.b at BDRGroup.com (Eli) Date: Tue, 18 Feb 2014 08:51:19 +0000 Subject: [Live-devel] RTP H.264 stream freezing on first frame using Message-ID: <6417F92C89FF5A4FA32A8F56070CA74002096AD5@QUEEN.BDRGroup.local> I have renamed the file to .h264 and it played back just fine with VLC player. I then went on to check the presentation times using testRTSPclient and indeed there was something wrong with them. After fixing the code of my custom video source used with wis-streamer, the stream works fine! Thanks, Ross! -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.lo at vivotek.com Tue Feb 18 02:12:47 2014 From: charles.lo at vivotek.com (charles.lo at vivotek.com) Date: Tue, 18 Feb 2014 10:12:47 +0000 Subject: [Live-devel] About RTSP Digest Authentication Message-ID: <91A36D96C859704A9045E63B9C78CA798296AE7A@MBS02.vivotek.tw> Hi I'm trying to do RTSP digest authentication between Vivotek's IP camera and VLC Player, and It seems that VLC Player does not support digest authentication in RFC-2617, but support digest authentication in RFC-2069. It means that our IP camera cannot response "401 Unauthorized" with qop="auth" which define in RFC-2617 when VLC player try to access live stream Therefore, the streamingserver which implement RFC-2617 will failed to do RTSP digest authentication with VLC player. Is this a correct understanding about this problem, any suggestion?? thanks very much! Best Regards, CharlesLo Engineer Project Development Department VIVOTEK INC. ?????????? 3F, No.192, Lien-Cheng Rd., Chung-Ho, Taipei County, Taiwan, R.O.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Feb 18 02:40:20 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Feb 2014 23:40:20 +1300 Subject: [Live-devel] About RTSP Digest Authentication In-Reply-To: <91A36D96C859704A9045E63B9C78CA798296AE7A@MBS02.vivotek.tw> References: <91A36D96C859704A9045E63B9C78CA798296AE7A@MBS02.vivotek.tw> Message-ID: <81C6BF6B-988A-402B-B42E-84932B83F3C5@live555.com> Charles, Thanks for the note. The issue that you raised was actually brought up almost 2 years ago - in March 2012 - and answered back then. See: http://lists.live555.com/pipermail/live-devel/2012-March/014839.html In summary: Vivotek should update their cameras to remove the qop="auth", string from their "WWW-Authenticate:" headers in RTSP. ps. When testing our RTSP/RTP client implementation against a server, it is best to *first* use our "openRTSP" application (see ) - rather than VLC - for testing. (Although VLC uses our RTSP/RTP client implementation, it is not our software, and does not show you the RTSP protocol exchange as well as "openRTSP" (or "testRTSPClient"). Only after you've tested your server with "openRTSP" shold you then try using VLC.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eli.b at BDRGroup.com Tue Feb 18 04:22:16 2014 From: eli.b at BDRGroup.com (Eli) Date: Tue, 18 Feb 2014 12:22:16 +0000 Subject: [Live-devel] RTP H.264 stream freezing on first frame using wis-streamer and VLC player Message-ID: <6417F92C89FF5A4FA32A8F56070CA74002096AE4@QUEEN.BDRGroup.local> I have renamed the file to .h264 and it played back just fine with VLC player. I then went on to check the presentation times using testRTSPclient and indeed there was something wrong with them. After fixing the code of my custom video source used with wis-streamer, the stream works fine! Thanks, Ross! -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Tue Feb 18 11:18:58 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Tue, 18 Feb 2014 20:18:58 +0100 Subject: [Live-devel] HEVC problem with start code ? Message-ID: <10262_1392751140_5303B223_10262_10099_1_1BE8971B6CFF3A4F97AF4011882AA25501564419C3E9@THSONEA01CMS01P.one.grp> Hi Ross, I made some tries with http://www.elecard.com/assets/files/other/clips/surfing.265 and http://www.elecard.com/assets/files/other/clips/Sintel_272p_logo.265 Using live555MediaServer to stream the file and openRTSP to record the stream. The resulting file is no more readable (for instance using VLC 2.1.3) as the original was. Comparing to the 2 files is not so obvious, the resulting file start with VPS, SPS, PPS, VPS, SPS, PPS, IDR_W_RADL, but the IDR has some differences. The original file : 00 00 01 26 01 AD 70 C8 D7 0D 55 E5 The resulting file : 00 00 00 01 26 01 C8 D7 0D 55 E5 It seems the start code 00 00 01 mess up the data ? Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Feb 18 14:00:24 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Feb 2014 11:00:24 +1300 Subject: [Live-devel] HEVC problem with start code ? In-Reply-To: <10262_1392751140_5303B223_10262_10099_1_1BE8971B6CFF3A4F97AF4011882AA25501564419C3E9@THSONEA01CMS01P.one.grp> References: <10262_1392751140_5303B223_10262_10099_1_1BE8971B6CFF3A4F97AF4011882AA25501564419C3E9@THSONEA01CMS01P.one.grp> Message-ID: <157C17CA-269D-4DE6-A561-FC6F6865CAFC@live555.com> > I made some tries with http://www.elecard.com/assets/files/other/clips/surfing.265 andhttp://www.elecard.com/assets/files/other/clips/Sintel_272p_logo.265 > > Using live555MediaServer to stream the file and openRTSP to record the stream. > The resulting file is no more readable (for instance using VLC 2.1.3) as the original was. So what? For the bazillionth time: VLC is not our software! VLC not being able to play a file usually has nothing to do with us. But, FWIW... My copy of VLC (2.1.3, running on Mac OS X) plays the "surfing.265" clip OK, but does not play the "Sintel_272p_logo.265" file at. Again, not our problem. Complain to a VLC mailing list about that. I tried running "openRTSP" to record the "surfing.265" file, streamed from a "LIVE555 Media Server". Strangely, after renaming the output file "video-H265-1" to have a ".265" filename suffix[*], VLC was unable to play the resulting file. As you noted, the only difference between the two files is that: 1/ The first NAL unit ("SPS") begins with 0x00 0x00 0x00 0x01 rather than 0x00 0x00 0x01. But that's not the problem, because VLC wouldn't play the file even when I deleted the first 0x00. 2/ The resulting file contains an extra copy of the "SPS", "PPS", and "VPS" NAL units at the start. ("openRTSP" (via the "H265VideoFileSink" class) adds these three NAL units at the start of the output file, in case they didn't appear in the stream itself.) This shouldn't be a problem for VLC (or at least, for whatever H.265 codec that it uses), but apparently it is. But once again - that's not our problem. Complain to a VLC mailing list about that. [*] For some dumb reason, VLC can play H.265 files with either a ".265" or ".h265" filename suffix, but can play H.264 files with only a ".h264" filename suffix - not a ".264" filename suffix. Complain to a VLC mailing list about that. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From morten at softwarehuset.dk Wed Feb 19 01:05:10 2014 From: morten at softwarehuset.dk (Morten S. Laursen) Date: Wed, 19 Feb 2014 10:05:10 +0100 Subject: [Live-devel] Support for VP8 packetization Message-ID: Hi I'm currently working with live555 and really appreciate the software, thank you. I currently have the video streaming up and running but as I am streaming over udp on a wifi link I have a significant packet loss. This causes more failed than successfull frames without packetization and effectively prevents bitrates much higher than 500k to work at all. I am testing with my own live555 based server and openRTSP as the client. I would therefore like to apply packetization in order to limit the influence of transmission errors. Is there any support for packetization with VP8 video streaming such as what google suggests in http://tools.ietf.org/html/draft-ietf-payload-vp8 or something similar. Thank you in advance Morten S. Laursen -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Feb 19 02:19:46 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Feb 2014 23:19:46 +1300 Subject: [Live-devel] Support for VP8 packetization In-Reply-To: References: Message-ID: <617A7538-CF0D-43B8-BDDD-2C455A3E4B82@live555.com> > I am testing with my own live555 based server and openRTSP as the client. > I would therefore like to apply packetization in order to limit the influence of transmission errors. Is there any support for packetization with VP8 video streaming such as what google suggests in http://tools.ietf.org/html/draft-ietf-payload-vp8 or something similar. Morten, I'm a bit puzzled by your question. By "packetization", are you referring just to the normal packing of VP8 payloads into RTP packets (as described in the Internet Draft that you referenced)? If so, then that is done automatically by our software - in particular, by the "VP8VideoRTPSink" class, which your "live555 based server" should already be using (in your "createNewRTPSink()" virtual function implementation, assuming that you're streaming via unicast). Or are you referring to something else? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From morten at softwarehuset.dk Wed Feb 19 02:51:13 2014 From: morten at softwarehuset.dk (Morten S. Laursen) Date: Wed, 19 Feb 2014 11:51:13 +0100 Subject: [Live-devel] Support for VP8 packetization In-Reply-To: <617A7538-CF0D-43B8-BDDD-2C455A3E4B82@live555.com> References: <617A7538-CF0D-43B8-BDDD-2C455A3E4B82@live555.com> Message-ID: Ross, Yes I was referring to the packing of VP8 payloads as done in the referenced draft. If that is already implemented and used automatically the problem must lie elsewhere as I am using the VP8VideoRTPSink class as you are referring to. As I understand the payload packing it should split the frames on image block boundaries and therefore a failed packet should only result in that block failing. However the behavior I'm seeing is that in the case of a failed packet the rest of the frame is corrupt. Therefore I assumed that the whole frame was packaged as one, instead of the sub-blocks in individual packets? Kind regards Morten S. Laursen 2014-02-19 11:19 GMT+01:00 Ross Finlayson : > I am testing with my own live555 based server and openRTSP as the client. > I would therefore like to apply packetization in order to limit the > influence of transmission errors. Is there any support for packetization > with VP8 video streaming such as what google suggests in > http://tools.ietf.org/html/draft-ietf-payload-vp8 or something similar. > > > Morten, > > I'm a bit puzzled by your question. By "packetization", are you referring > just to the normal packing of VP8 payloads into RTP packets (as described > in the Internet Draft that you referenced)? If so, then that is done > automatically by our software - in particular, by the "VP8VideoRTPSink" > class, which your "live555 based server" should already be using (in your > "createNewRTPSink()" virtual function implementation, assuming that you're > streaming via unicast). > > Or are you referring to something else? > > > 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 Wed Feb 19 03:48:26 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Feb 2014 00:48:26 +1300 Subject: [Live-devel] Support for VP8 packetization In-Reply-To: References: <617A7538-CF0D-43B8-BDDD-2C455A3E4B82@live555.com> Message-ID: <318E9DD0-9721-49DF-8CE7-8989A8DAEFD7@live555.com> > Yes I was referring to the packing of VP8 payloads as done in the referenced draft. If that is already implemented and used automatically the problem must lie elsewhere as I am using the VP8VideoRTPSink class as you are referring to. > As I understand the payload packing it should split the frames on image block boundaries and therefore a failed packet should only result in that block failing. No, not in our implementation. If a frame is fragmented over multiple RTP packets, then the loss of *any* of these packets will cause the whole frame to be discarded by the receiver. The VP8 RTP payload format specification does, however, allow for VP8 frames to be split on 'partition' boundaries when packed into RTP packets, in such a way that a receiver *could*, conceivably, receive just some partitions of a VP8 frame if packets are lost. We don't implement this, however (because we don't parse VP8 frames at all, and therefore can't know where 'partitions' start and end within frames). (In any case, this would be useful only if your decoder were able to handle incomplete frames (consisting of some, but not all, 'partitions').) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From morten at softwarehuset.dk Wed Feb 19 04:41:19 2014 From: morten at softwarehuset.dk (Morten S. Laursen) Date: Wed, 19 Feb 2014 13:41:19 +0100 Subject: [Live-devel] Support for VP8 packetization In-Reply-To: <318E9DD0-9721-49DF-8CE7-8989A8DAEFD7@live555.com> References: <617A7538-CF0D-43B8-BDDD-2C455A3E4B82@live555.com> <318E9DD0-9721-49DF-8CE7-8989A8DAEFD7@live555.com> Message-ID: Okay, that makes more sense, it was the partition boundary splitting which I was referring to and not the blocks, please excuse my misuse of terms. I assume the codec on the receiving end would be able to handle the missing partitions using the error concealment method already built into the codec, and the client therefore would not have to adapt to the new behavior other than to enable error concealment. However if there exists no information of the partition boundaries, it makes sense that it is not possible to implement. Thank you for taking the time to answer Kind regards Morten S. Laursen 2014-02-19 12:48 GMT+01:00 Ross Finlayson : > Yes I was referring to the packing of VP8 payloads as done in the > referenced draft. If that is already implemented and used automatically the > problem must lie elsewhere as I am using the VP8VideoRTPSink class as you > are referring to. > As I understand the payload packing it should split the frames on image > block boundaries and therefore a failed packet should only result in that > block failing. > > > No, not in our implementation. If a frame is fragmented over multiple RTP > packets, then the loss of *any* of these packets will cause the whole frame > to be discarded by the receiver. > > The VP8 RTP payload format specification does, however, allow for VP8 > frames to be split on 'partition' boundaries when packed into RTP packets, > in such a way that a receiver *could*, conceivably, receive just some > partitions of a VP8 frame if packets are lost. We don't implement this, > however (because we don't parse VP8 frames at all, and therefore can't know > where 'partitions' start and end within frames). (In any case, this would > be useful only if your decoder were able to handle incomplete frames > (consisting of some, but not all, 'partitions').) > > 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 ELIMCO.dmartinez at navantia.es Wed Feb 19 04:12:20 2014 From: ELIMCO.dmartinez at navantia.es (=?iso-8859-1?Q?Mart=EDnez_Contador=2C_Daniel_=5BELIMCO=5D_=28CA=29?=) Date: Wed, 19 Feb 2014 12:12:20 +0000 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: References: Message-ID: testMPEG4VideoStreamer.exe starts overusing the CPU when a player tears the session. The overuse happens with binaries from CYGWIN, but not with MINGW. In my setup, testMPEG4VideoStreamer, just launched, uses <1% from CPU. When a client connects (I'm using VLC) the CPU consumption remains stable. When the client disconnects (tear) the CPU consumption rises to 10-12%. Connecting again doesn't make the CPU return to normal consumption. It happens too with testOnDemandRTSPServer. I haven't tried other videos. These are the versions I'm using: Live555: live.2014.02.17 (although I found this error in 2014.01.07) Cygwin: from package 1.7.28-2 (32bits) gcc: from package 4.8.2-2 My video test file: http://live555-for-win32.googlecode.com/svn-history/r4/trunk/Projects/VC2003/testMPEG4VideoStreamer/Debug/test.m4e If someone could check this and provide a workaround if not a solution... I cannot switch from cygwin at this stage and that 10% is significant at the moment. I need to run several instances in different virtual interfaces (about 40) in the same computer. They won't be encoding or sending at the same time (usually 1-4, rarely above 8), but there may be clients rotating over all the 40 and a CPU usage around 400% is hardly acceptable :) Thanks. Daniel Mart?nez Contador Logotipo Elimco ELIMCO- Soluciones Integrales S.A. Navantia - Sistemas de Control Ctra. Algameca, s/n 30205 Cartagena (Murcia) Tlfo: 968 323 387 Email: elimco.dmartinez at navantia.es www.elimco.com NAVANTIA ______________________________ Este mensaje, y cualquier fichero anexo al mismo, contiene informacion de caracter confidencial dirigida exclusivamente a su(s) destinatario(s) y, en su caso, sometida a secreto profesional. Queda prohibida su difusion, copia o distribucion a terceros sin la previa autorizacion escrita. Si Vd. ha recibido este mensaje por error, se ruega lo comunique inmediatamente por esta misma via y proceda a su completa eliminacion. The information in this e-mail, and in any attachments, is confidential and, if any, protected by a professional privilege, and intended solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, copy or distribution of this information is prohibited without the prior written consent. If you have received this communication in error, please notify the sender by reply e-mail and delete it. ______________________________ From michel.promonet at thalesgroup.com Wed Feb 19 04:00:35 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Wed, 19 Feb 2014 13:00:35 +0100 Subject: [Live-devel] HEVC problem with start code ? In-Reply-To: <157C17CA-269D-4DE6-A561-FC6F6865CAFC@live555.com> References: <10262_1392751140_5303B223_10262_10099_1_1BE8971B6CFF3A4F97AF4011882AA25501564419C3E9@THSONEA01CMS01P.one.grp> <157C17CA-269D-4DE6-A561-FC6F6865CAFC@live555.com> Message-ID: <22361_1392811237_53049CE5_22361_2111_1_1BE8971B6CFF3A4F97AF4011882AA25501564419CF20@THSONEA01CMS01P.one.grp> Hi Ross, I guess the problem is deeper. Modifying the start code of the first IDR frame of surfing.265 from 00 00 01 to 00 00 00 01, but it does not solve the problem. The result file still contain an IDR frame : 00 00 00 01 26 01 C8 D7 0D 55 E5 But the original file start with an IDR frame: 00 00 00 01 26 01 AD 70 C8 D7 0D 55 E5 It seems "AD 70" are missing ? The problem doesnot seems related to VLC, ffmpeg complains also "PPS id out of range", "Error parsing NAL unit #0" I will let you know if I found something interesting. Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : mardi 18 f?vrier 2014 23:00 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] HEVC problem with start code ? I made some tries with http://www.elecard.com/assets/files/other/clips/surfing.265 andhttp://www.elecard.com/assets/files/other/clips/Sintel_272p_logo.265 Using live555MediaServer to stream the file and openRTSP to record the stream. The resulting file is no more readable (for instance using VLC 2.1.3) as the original was. So what? For the bazillionth time: VLC is not our software! VLC not being able to play a file usually has nothing to do with us. But, FWIW... My copy of VLC (2.1.3, running on Mac OS X) plays the "surfing.265" clip OK, but does not play the "Sintel_272p_logo.265" file at. Again, not our problem. Complain to a VLC mailing list about that. I tried running "openRTSP" to record the "surfing.265" file, streamed from a "LIVE555 Media Server". Strangely, after renaming the output file "video-H265-1" to have a ".265" filename suffix[*], VLC was unable to play the resulting file. As you noted, the only difference between the two files is that: 1/ The first NAL unit ("SPS") begins with 0x00 0x00 0x00 0x01 rather than 0x00 0x00 0x01. But that's not the problem, because VLC wouldn't play the file even when I deleted the first 0x00. 2/ The resulting file contains an extra copy of the "SPS", "PPS", and "VPS" NAL units at the start. ("openRTSP" (via the "H265VideoFileSink" class) adds these three NAL units at the start of the output file, in case they didn't appear in the stream itself.) This shouldn't be a problem for VLC (or at least, for whatever H.265 codec that it uses), but apparently it is. But once again - that's not our problem. Complain to a VLC mailing list about that. [*] For some dumb reason, VLC can play H.265 files with either a ".265" or ".h265" filename suffix, but can play H.264 files with only a ".h264" filename suffix - not a ".264" filename suffix. Complain to a VLC mailing list about that. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Feb 19 10:31:39 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Feb 2014 07:31:39 +1300 Subject: [Live-devel] HEVC problem with start code ? In-Reply-To: <22361_1392811237_53049CE5_22361_2111_1_1BE8971B6CFF3A4F97AF4011882AA25501564419CF20@THSONEA01CMS01P.one.grp> References: <10262_1392751140_5303B223_10262_10099_1_1BE8971B6CFF3A4F97AF4011882AA25501564419C3E9@THSONEA01CMS01P.one.grp> <157C17CA-269D-4DE6-A561-FC6F6865CAFC@live555.com> <22361_1392811237_53049CE5_22361_2111_1_1BE8971B6CFF3A4F97AF4011882AA25501564419CF20@THSONEA01CMS01P.one.grp> Message-ID: > It seems ?AD 70? are missing ? Finally! An issue with our software (rather than VLC :-) There was a bug in the way in which our code (and thus "openRTSP") received the H.265/RTP stream. I've just installed a new version - 2014.02.19 - 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 Wed Feb 19 10:33:26 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Feb 2014 07:33:26 +1300 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: References: Message-ID: <7E20DBAF-BF86-432B-BECB-4A5E2D696F54@live555.com> > testMPEG4VideoStreamer.exe starts overusing the CPU when a player tears > the session. > The overuse happens with binaries from CYGWIN, but not with MINGW. I wasn't able to reproduce this on either MacOS X or FreeBSD. If you find a bug, please let us know. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Wed Feb 19 14:55:59 2014 From: warren at etr-usa.com (Warren Young) Date: Wed, 19 Feb 2014 15:55:59 -0700 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: References: Message-ID: <5305367F.5080702@etr-usa.com> On 2/19/2014 05:12, Mart?nez Contador, Daniel [ELIMCO] (CA) wrote: > The overuse happens with binaries from CYGWIN, but not with MINGW. So you changed the development platform, but you blame Live555? Science says that if you change one variable and the behavior changes, chances are that the thing you changed caused the behavior difference. It is possible that Live555 is using the POSIX layer in a way that particularly annoys Cygwin, but I'd say the burden is on you to prove that, given that the library performs well on every other POSIXy OS. Cygwin tries very hard to be as minimal a layer between your program and the Windows kernel as it can be, but in certain places, it has to be thicker than we'd like to emulate the POSIX semantics programs built on Cygwin expect, in terms of the Windows kernel API, which often isn't implemented with POSIX-like semantics. I/O is one of these places, and Live555 is all about I/O. From finlayson at live555.com Wed Feb 19 23:53:15 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Feb 2014 20:53:15 +1300 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: <5305367F.5080702@etr-usa.com> References: <5305367F.5080702@etr-usa.com> Message-ID: > It is possible that Live555 is using the POSIX layer in a way that particularly annoys Cygwin, but I'd say the burden is on you to prove that, given that the library performs well on every other POSIXy OS. > > Cygwin tries very hard to be as minimal a layer between your program and the Windows kernel as it can be, but in certain places, it has to be thicker than we'd like to emulate the POSIX semantics programs built on Cygwin expect, in terms of the Windows kernel API, which often isn't implemented with POSIX-like semantics. I/O is one of these places, and Live555 is all about I/O. I must admit that I don't understand why so many people are trying to develop server applications (LIVE555-based or otherwise) on Windows. The Windows OS is not well-suited for running servers. I can understand people wanting to develop *client* applications for Windows, as there are still a lot of Windows PCs/laptops out there. But if you're developing a server, then a Unix-based platform (and by "Unix-based", I include Linux and Mac OS X) is usually a much better choice. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Feb 20 00:34:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Feb 2014 21:34:38 +1300 Subject: [Live-devel] RTCPInstance::onExpire do not unscheduled from desctructor In-Reply-To: References: Message-ID: > It seems RTCPInstance was destroyed due to closing subsessions, but unshedule() of onExpire() was not performed. Unfortunately I can't see how that could be, because "RTCPInstance" is a subclass of "Medium", and the "Medium" destructor explicitly unschedules the 'on expire' task. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbrimer at oncamgrandeye.com Thu Feb 20 05:59:28 2014 From: mbrimer at oncamgrandeye.com (Michael Brimer) Date: Thu, 20 Feb 2014 13:59:28 +0000 Subject: [Live-devel] Changes to make it easier to subclass ServerMediaSession and set packet buffer size Message-ID: Hi, I would like to request a few changes to liveMedia to assist with subclassing and server instantiation. Some background: I'm working on a network camera that needs to be ONVIF profile G compliant. It records matroska video clips which are then represented to an ONVIF client as a single "Recording" with time discontinuities. This means that the SDP description needs to reflect the whole "Recording" rather than the clips which comprise it. Consequently, this information needs to come from a database rather than being returned by video track information discovered in a file. I have an implementation of this working correctly. However in order to override as little library functionality as possible I found it necessary to patch some items in the library. Of course, I can keep doing that but I am submitting the patch in the hope that some/all of the issues identified could be adopted by the liveMedia library. Here is a summary of the changes along with a reason for each change. 1. ServerMediaSession::generateSDPDescription() becomes a virtual method. Allows subclass to generate the SDP description in an independent manner e.g. database lookup. 2. ServerMediaSession::duration() becomes a virtual method. Allows subclass to generate the duration in an independent manner e.g. database lookup. 3. Add a virtual method called ServerMediaSession::mediaSdpLines() and modify the implementation of ServerMediaSession::generateSDPDescription() to call mediaSdpLines() instead of calling subsession->sdpLines() directly. Allows subclass to intercept each media track description and append extra attributes. ONVIF complieance requires tracks to be marked with extension attributes e.g. a=x-onvif-track:VIDEO001. 4. Modify MatroskaFile::createSourceForStreaming() implementation to check for larger values of OutPacketBuffer::maxSize before setting 300000 value. Allows server instantiation to set a larger value without it being ignored. With a full field-of-view I'm seeing a few warning messages being emitted during replay and therefore a larger value than 300000 is recommended. A patch file is attached for your convenience. If you need any further information please let me know. Kind Regards, Mike Brimer This communication is for the exclusive use of the addressee and may contain information that is private and confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication and its attachments is strictly prohibited. If you have received this information in error please contact the sender and delete the communication from your system. Any views or opinions presented are solely those of the author and do not necessarily represent those of Oncam Grandeye unless specifically stated. This message has been scanned for malware by Websense. www.websense.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 001-subclass.patch Type: application/octet-stream Size: 4272 bytes Desc: 001-subclass.patch URL: From finlayson at live555.com Thu Feb 20 09:39:04 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 Feb 2014 06:39:04 +1300 Subject: [Live-devel] Changes to make it easier to subclass ServerMediaSession and set packet buffer size In-Reply-To: References: Message-ID: <63747FCB-1999-4346-8AAB-90B65DC5157D@live555.com> Michael, To begin with, it's important to note that 'ONVIF' is an industry consortium (and one that Live Networks, Inc. does not belong to) - not a standards organization. The relevant standards organization here (the one that we belong to, and whose specifications we try to adhere to) is the IETF. For the most part, 'ONVIF standards' are really just IETF standards that they have referenced 'as is'; in this case, we will try to support them ourselves. In some cases, however, 'ONVIF' may have made their own changes to SDP (or other IETF standards), without describing them in an IETF RFC or Internet-Draft; in that case, I feel no compulsion to support them in the "LIVE555 Streaming Media" software (and certainly not 'for free'). But having said that, let's look at each of the specific changes that you requested: > 1. ServerMediaSession::generateSDPDescription() becomes a virtual method. Allows subclass to generate the SDP description in an independent manner e.g. database lookup. The reason I can't do this is that the existing "generateSDPDescription()" code is important. It explicitly generates 'session-level' SDP lines, followed by 'media-level' SDP lines for each "ServerMediaSubsession" - by calling "sdpLines()" (which, BTW, *is* a virtual function) on each subsession. If I were to make it possible for subclasses to completely replace this code, then there's no guarantee that the resulting SDP would be (1) standards compliant, and (2) in a form that would allow a client to properly operate on the session/subsessions. However, what I *might* do - sometime in the future - is provide a mechanism to allow developers to add their own 'session-level' attributes (i.e., beginning with "a=x-") to a SDP description. Perhaps that would give you what you want here?? > 2. ServerMediaSession::duration() becomes a virtual method. Allows subclass to generate the duration in an independent manner e.g. database lookup. Note that "ServerMedia*Sub*session::duration()" is already a virtual function, so your "ServerMediaSubsession" subclasses can redefine "duration()" to return whatever you want. But the existing "ServerMediaSession::duration()" code is important (although admittedly a bit 'hacky'), and the code in several places makes assumptions about how "ServerMediaSession::duration()" works (basically, by returning the maximum of all the subsession "duration()"s, along with an indication of whether or not the subsession "duration()"s differ). So it can't be changed arbitrarily. Note that the child "ServerMediaSubsession"s are assumed to be 'concurrent' tracks within the parent "ServerMediaSession", so that the "duration()" of the parent is simply the maximum of the "duration()" of the children. I hope you're not proposing that media-level SDP lines (i.e., generated from "ServerMediaSubsession"s) within a SDP description mean something different that this. That's certainly not something that I could support, because that would be a non-standard interpretation of SDP (unless the SDP description also includes some IETF-defined 'grouping' mechanism that indicates otherwise). > 3. Add a virtual method called ServerMediaSession::mediaSdpLines() and modify the implementation of ServerMediaSession::generateSDPDescription() to call mediaSdpLines() instead of calling subsession->sdpLines() directly. This seems unnecessary, because "ServerMediaSubsession::sdpLines()" is already a virtual function. > 4. Modify MatroskaFile::createSourceForStreaming() implementation to check for larger values of OutPacketBuffer::maxSize before setting 300000 value. Allows server instantiation to set a larger value without it being ignored. With a full field-of-view I'm seeing a few warning messages being emitted during replay and therefore a larger value than 300000 is recommended. Yes, this is a good point. What I'll do (in the next release of the software) is define a new function "OutPacketBuffer::increaseMaxSizeTo(unsigned)" that doesn't change "OutPacketBuffer::maxSize" if it's already less than the specified value - and then change "MatroskaFile::createSourceForStreaming()" to call this new function instead. Needless to say, you are, of course, welcome to make whatever changes you want to your own copy of the code, provided that - in doing so - you comply with the LGPL; see http://www.live555.com/liveMedia/faq.html#copyright-and-license Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Feb 21 00:44:57 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 Feb 2014 18:44:57 +1000 Subject: [Live-devel] Destructor of SocketDescriptor seems do things wrong. In-Reply-To: References: Message-ID: > I use liveMedia library 2014.01.24 to do streaming via RTSP over TCP. When client is still connecting to server and I delete RTSPServer, > my system will crash. Thanks for the report. I have fixed a bug that I think was causing this problem. Please upgrade to the latest version of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbrimer at oncamgrandeye.com Fri Feb 21 02:52:59 2014 From: mbrimer at oncamgrandeye.com (Michael Brimer) Date: Fri, 21 Feb 2014 10:52:59 +0000 Subject: [Live-devel] Changes to make it easier to subclass ServerMediaSession and set packet buffer size In-Reply-To: <63747FCB-1999-4346-8AAB-90B65DC5157D@live555.com> References: <63747FCB-1999-4346-8AAB-90B65DC5157D@live555.com> Message-ID: Hi Ross, Thanks for taking the time to consider my requests. I understand your wish to support IETF standards primarily and I take the hint about not 'for free' (that may be an option). Yes, ONVIF have added some extensions to achieve their goals. My understanding is that these extensions are allowed by the SDP and RTP standards. In case you are interested, I believe the ONVIF objective is to represent a set of non-contiguous media clips as a single container (a bit like a VOB but without the continuity of chapters). Imagine two video clips with duration T1 to T2 and T3 to T4 then the SDP would return a duration of T4-T1. During replay, the RTP timestamp header extension is used to indicate to the client the discontinuity at the T2 to T3 boundary. I don't think it's intended for human viewing in a player but for transfer of recordings from a camera to an archiver. I think this uses a valid timestamp header extension of the RTP spec but "bends" the SDP specification as it is not envisaged but not forbidden. However it is an unusual use case so is probably not of interest to the majority of LIVE555 stakeholders. In response to your specific points: 1. I think the ability of being able to add session level attributes of the form "a=x-" might well be useful to some people. As described above, it was not my objective but I can achieve that in other ways e.g subclassing the DESCRIBE handler which is already virtual although it is a bit more clunky. Thanks for considering it. 2. Here I was trying to work around the assumption that the session duration is the maximum of the subsessions. Yes indeed I was trying to return a duration for the entire collection i.e. T4-T1 in my example. I don't think this violates SDP but I can understand if you think it does and don't want to allow subclassing. 3. This was to handle a quirk of the ONVIF spec that wants each track enumerated with a special attribute e.g. video tracks get a=x-onvif-track:VIDEO001, 002, ... and audio tracks get a=x-onvif-track:AUDIO001, 002, ... and so forth. To me it seems a complete waste of effort since an SDP parser can easily work this out from the media level blocks following the session level lines. But I didn't write the spec, just the poor guy trying to comply with it. :( I know the subsessions are already virtual but by appending it in the ServerMediaSession I didn't have to add it for each type of video and audio subsession class in use. 4. This was always a completely different problem domain to 1, 2 & 3. Thanks for adding that, I think it will be useful to everyone. As you suggest, I can make changes under the LGPL but just thought I would check first whether you wanted to adopt any of them. Again thanks for taking the time to consider my request. Kind Regards, Mike Brimer Oncam Grandeye From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 20 February 2014 17:39 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Changes to make it easier to subclass ServerMediaSession and set packet buffer size Michael, To begin with, it's important to note that 'ONVIF' is an industry consortium (and one that Live Networks, Inc. does not belong to) - not a standards organization. The relevant standards organization here (the one that we belong to, and whose specifications we try to adhere to) is the IETF. For the most part, 'ONVIF standards' are really just IETF standards that they have referenced 'as is'; in this case, we will try to support them ourselves. In some cases, however, 'ONVIF' may have made their own changes to SDP (or other IETF standards), without describing them in an IETF RFC or Internet-Draft; in that case, I feel no compulsion to support them in the "LIVE555 Streaming Media" software (and certainly not 'for free'). But having said that, let's look at each of the specific changes that you requested: 1. ServerMediaSession::generateSDPDescription() becomes a virtual method. Allows subclass to generate the SDP description in an independent manner e.g. database lookup. The reason I can't do this is that the existing "generateSDPDescription()" code is important. It explicitly generates 'session-level' SDP lines, followed by 'media-level' SDP lines for each "ServerMediaSubsession" - by calling "sdpLines()" (which, BTW, *is* a virtual function) on each subsession. If I were to make it possible for subclasses to completely replace this code, then there's no guarantee that the resulting SDP would be (1) standards compliant, and (2) in a form that would allow a client to properly operate on the session/subsessions. However, what I *might* do - sometime in the future - is provide a mechanism to allow developers to add their own 'session-level' attributes (i.e., beginning with "a=x-") to a SDP description. Perhaps that would give you what you want here?? 2. ServerMediaSession::duration() becomes a virtual method. Allows subclass to generate the duration in an independent manner e.g. database lookup. Note that "ServerMedia*Sub*session::duration()" is already a virtual function, so your "ServerMediaSubsession" subclasses can redefine "duration()" to return whatever you want. But the existing "ServerMediaSession::duration()" code is important (although admittedly a bit 'hacky'), and the code in several places makes assumptions about how "ServerMediaSession::duration()" works (basically, by returning the maximum of all the subsession "duration()"s, along with an indication of whether or not the subsession "duration()"s differ). So it can't be changed arbitrarily. Note that the child "ServerMediaSubsession"s are assumed to be 'concurrent' tracks within the parent "ServerMediaSession", so that the "duration()" of the parent is simply the maximum of the "duration()" of the children. I hope you're not proposing that media-level SDP lines (i.e., generated from "ServerMediaSubsession"s) within a SDP description mean something different that this. That's certainly not something that I could support, because that would be a non-standard interpretation of SDP (unless the SDP description also includes some IETF-defined 'grouping' mechanism that indicates otherwise). 3. Add a virtual method called ServerMediaSession::mediaSdpLines() and modify the implementation of ServerMediaSession::generateSDPDescription() to call mediaSdpLines() instead of calling subsession->sdpLines() directly. This seems unnecessary, because "ServerMediaSubsession::sdpLines()" is already a virtual function. 4. Modify MatroskaFile::createSourceForStreaming() implementation to check for larger values of OutPacketBuffer::maxSize before setting 300000 value. Allows server instantiation to set a larger value without it being ignored. With a full field-of-view I'm seeing a few warning messages being emitted during replay and therefore a larger value than 300000 is recommended. Yes, this is a good point. What I'll do (in the next release of the software) is define a new function "OutPacketBuffer::increaseMaxSizeTo(unsigned)" that doesn't change "OutPacketBuffer::maxSize" if it's already less than the specified value - and then change "MatroskaFile::createSourceForStreaming()" to call this new function instead. Needless to say, you are, of course, welcome to make whatever changes you want to your own copy of the code, provided that - in doing so - you comply with the LGPL; see http://www.live555.com/liveMedia/faq.html#copyright-and-license Ross Finlayson Live Networks, Inc. http://www.live555.com/ Click here to report this email as spam. This message has been scanned for malware by Websense. www.websense.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Tue Feb 18 04:42:22 2014 From: fantasyvideo at 126.com (Tony) Date: Tue, 18 Feb 2014 20:42:22 +0800 (CST) Subject: [Live-devel] Regarding the seek and fast forward /reverse play in rtsp server Message-ID: <374f133d.2d0b4.1444504bd6e.Coremail.fantasyvideo@126.com> Hi Ross, I read the faq in live555 website about the trick play, it only said the four virtual functions needs to be supported. But as the result, the vlc would drop audio buffer, so I guess the fPresentationTime should be changed too? Is it right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Feb 21 16:40:56 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 Feb 2014 10:40:56 +1000 Subject: [Live-devel] Changes to make it easier to subclass ServerMediaSession and set packet buffer size In-Reply-To: References: <63747FCB-1999-4346-8AAB-90B65DC5157D@live555.com> Message-ID: <9E23D002-A166-476C-8965-7A221324D8AA@live555.com> > Yes, ONVIF have added some extensions to achieve their goals. My understanding is that these extensions are allowed by the SDP and RTP standards. In case you are interested, I believe the ONVIF objective is to represent a set of non-contiguous media clips as a single container (a bit like a VOB but without the continuity of chapters). Imagine two video clips with duration T1 to T2 and T3 to T4 then the SDP would return a duration of T4-T1. If you like, feel free to post a specific example of the type of SDP that you want your server to be able to handle, along with a reference to a document that describes the intended semantics of this uses of SDP. > During replay, the RTP timestamp header extension is used to indicate to the client the discontinuity at the T2 to T3 boundary. I don?t think it?s intended for human viewing in a player but for transfer of recordings from a camera to an archiver. I think this uses a valid timestamp header extension of the RTP spec but ?bends? the SDP specification as it is not envisaged but not forbidden. OK, then you're definitely out of luck (for now), because we currently don't implement RTP header extensions. > However it is an unusual use case so is probably not of interest to the majority of LIVE555 stakeholders. I am the only "LIVE555 stakeholder" :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Feb 21 17:13:32 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 Feb 2014 11:13:32 +1000 Subject: [Live-devel] Regarding the seek and fast forward /reverse play in rtsp server In-Reply-To: <374f133d.2d0b4.1444504bd6e.Coremail.fantasyvideo@126.com> References: <374f133d.2d0b4.1444504bd6e.Coremail.fantasyvideo@126.com> Message-ID: > I read the faq in live555 website about the trick play, it only said the four virtual functions needs to be supported. > But as the result, the vlc would drop audio buffer, so I guess the fPresentationTime should be changed too? > Is it right? The "presentation time" represents the time at which the media should be 'presented' (i.e., displayed or played) to a receiver. So, of course, you need to make sure that it's aligned with 'wall clock time', even if you are doing fast-forward or reverse-play. E.g., if you're doing fast-forward 2x, your server's presentation times should *not* increase 2x as fast as normal. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From louis_latreille at hotmail.com Fri Feb 21 20:06:47 2014 From: louis_latreille at hotmail.com (Louis Latreille) Date: Fri, 21 Feb 2014 23:06:47 -0500 Subject: [Live-devel] Error decoding stream Message-ID: Hi live555 team, I was wondering if the stream received with the "testmp3receiver" had any ID3 tag in it, or was it only pure mp3 frames. I am getting a sync error when giving the mp3 file receiving the stream to the decoder (libmad) an I've been told that it needed only mp3 frames. Any thoughts? Louis From finlayson at live555.com Sat Feb 22 22:43:56 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 23 Feb 2014 16:43:56 +1000 Subject: [Live-devel] Error decoding stream In-Reply-To: References: Message-ID: <132F0D84-A028-4BFF-B0B8-53B4B4EF186E@live555.com> > I was wondering if the stream received with the "testmp3receiver" had any ID3 tag in it, or was it only pure mp3 frames. "testMP3Receiver" delivers data under the assumption that the incoming stream was RTP-encoded MPEG-1 or 2 audio data (i.e., including MP3) that was packetized according to RFC 2250. If the server (i.e., transmitting application) was "testMP3Streamer", then this data should be MPEG audio only (no ID3 tag or anything else). If, however, the server (i.e., transmitting application) was something else, then who knows... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pallela.venkatkarthik at vvdntech.com Sun Feb 23 19:44:00 2014 From: pallela.venkatkarthik at vvdntech.com (Pallela Venkat Karthik) Date: Mon, 24 Feb 2014 09:14:00 +0530 Subject: [Live-devel] kill() is called from one of the processes of testOnDemandRTSPServer Message-ID: Hi, I am using testOnDemandRTSPServer to stream a sensor video.I get streaming good on wifi (wifi module on USB interface)for few minutes and after that streamer process gets killed due to SIGKILL I used strace tool to trace, what is causing it. Details: When I run testOnDemandRTSPServer, 4 processes of testOnDemandRTSPServer are created The second process in the order of increasing process id's continuously calls poll() and getpid() system calls,after some time ,it calls kill() with SIGKILL to other testOnDemandRTSPServer processes. Could you help me resolve when it can occur and prevent this issue. I am using Embedded Linux, Ubuntu 2.6.9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ELIMCO.dmartinez at navantia.es Mon Feb 24 05:36:28 2014 From: ELIMCO.dmartinez at navantia.es (=?iso-8859-1?Q?Mart=EDnez_Contador=2C_Daniel_=5BELIMCO=5D_=28CA=29?=) Date: Mon, 24 Feb 2014 13:36:28 +0000 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: References: Message-ID: Re: Overuse of CPU in binaries of CYGWIN >> Cygwin tries very hard to be as minimal a layer between >> your program and the Windows kernel as it can be, but in >> certain places, it has to be thicker than we'd like to >> emulate the POSIX semantics programs built on Cygwin >> expect, in terms of the Windows kernel API, which often >> isn't implemented with POSIX-like semantics. I/O is one >> of these places, and Live555 is all about I/O. This is an educated guess. In Cygwin the RTSPClientConnection socket doesn't close explicitly after a TEAR. The read bitmask in the call to select in BasicTaskScheduler remains active and the call returns immediately by some reason which doesn't apply to other posixes. Modifying handleCmd_TEARDOWN so that the RTSPClientSession deletes itself and its ourClientConnection closes sockets seem to restore normal CPU usage after a TEAR with no (evident) adverse effects. > I must admit that I don't understand why so many people > are trying to develop server applications (LIVE555-based > or otherwise) on Windows. The Windows OS is not > well-suited for running servers. I mostly agree. What I'm doing will be part of both a server and a test/development tool. The server will run in Windows among other servers already in Windows, all of them will be eventually ported to Linux (hopefully). The test tool will have to run in Windows too however. Daniel Mart?nez Contador ELIMCO- Soluciones Integrales S.A. Navantia - Sistemas de Control Ctra. Algameca, s/n 30205 Cartagena (Murcia) Tlfo: 968 323 387 Email: elimco.dmartinez at navantia.es www.elimco.com NAVANTIA ______________________________ Este mensaje, y cualquier fichero anexo al mismo, contiene informacion de caracter confidencial dirigida exclusivamente a su(s) destinatario(s) y, en su caso, sometida a secreto profesional. Queda prohibida su difusion, copia o distribucion a terceros sin la previa autorizacion escrita. Si Vd. ha recibido este mensaje por error, se ruega lo comunique inmediatamente por esta misma via y proceda a su completa eliminacion. The information in this e-mail, and in any attachments, is confidential and, if any, protected by a professional privilege, and intended solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, copy or distribution of this information is prohibited without the prior written consent. If you have received this communication in error, please notify the sender by reply e-mail and delete it. ______________________________ From nikolai.vorontsov at quadrox.be Tue Feb 25 06:17:55 2014 From: nikolai.vorontsov at quadrox.be (Nikolai Vorontsov) Date: Tue, 25 Feb 2014 15:17:55 +0100 Subject: [Live-devel] Possible error after code analysis In-Reply-To: <132F0D84-A028-4BFF-B0B8-53B4B4EF186E@live555.com> References: <132F0D84-A028-4BFF-B0B8-53B4B4EF186E@live555.com> Message-ID: <6D82EC1FD7BDB04EA79ED1CA69EE26ED260A5E@s-giant.herent.quadrox.be> Hello Ross, I've run code analysis tool against the Live555 and found two suspicious places, which might be an error: Live555 from 2014/02/19 H264or5VideoStreamFramer.cpp, line 696 (681): unsigned num_negative_pics = 0; unsigned num_positive_pics = 0; >>> for (unsigned j = 0; j < num_negative_pics+num_positive_pics; ++j) { so, these variables are not changed before the cycle and it's never run. StreamParser.cpp, line 88 and 105: return (unsigned)lastByte &~ ((~0)< From warren at etr-usa.com Tue Feb 25 08:17:30 2014 From: warren at etr-usa.com (Warren Young) Date: Tue, 25 Feb 2014 09:17:30 -0700 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: References: Message-ID: <530CC21A.7050607@etr-usa.com> On 2/24/2014 06:36, Mart?nez Contador, Daniel [ELIMCO] (CA) wrote: > > This is an educated guess. In Cygwin the RTSPClientConnection > socket doesn't close explicitly after a TEAR. The read bitmask > in the call to select in BasicTaskScheduler remains active > and the call returns immediately by some reason which doesn't > apply to other posixes. If the remote peer closes a TCP socket, select() will mark it readable, because it wants you to call recv() one last time and get -1, which is how BSD sockets (and Winsock) signal that condition. In a program that never makes that last recv() call, select() will continue to mark that socket readable forever. This is a popular way to get into an infinite loop. I'd be surprised if Live555 makes this mistake, because it isn't Winsock specific. If Live555 has this bug, it should affect BSD sockets based systems, too. Please post your patch, so we can see if this is indeed the problem it fixes. Winsock semantics are pretty darn close to BSD sockets semantics. Once upon a time, in a galaxy far far away (on the t axis) Winsock had a 64-bit socket limit that affected Cygwin, too. That was fixed about 15 years ago in Cygwin, and earlier in Microsoft native stacks. Cygwin still defines FD_SETSIZE to 64 by default, and Live555 doesn't override it. This does mean that a default build of Live555 on Cygwin won't be able to open more than 64 sockets. Since you eat 3 for stdio and each RTSP connection takes 3 (one for RTSP and one each for audio and video RTP) this means you will run into trouble with RTSP with only 21 simultaneous RTSP streams. Ross, you should say "#define FD_SETSIZE 1024" or similar #ifdef _WIN32. From warren at etr-usa.com Tue Feb 25 09:01:47 2014 From: warren at etr-usa.com (Warren Young) Date: Tue, 25 Feb 2014 10:01:47 -0700 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: <530CC21A.7050607@etr-usa.com> References: <530CC21A.7050607@etr-usa.com> Message-ID: <530CCC7B.9070602@etr-usa.com> On 2/25/2014 09:17, Warren Young wrote: > because it wants you to call recv() one last time and get -1, which is > how BSD sockets (and Winsock) signal that condition. I meant 0, of course. From finlayson at live555.com Tue Feb 25 13:33:21 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Feb 2014 07:33:21 +1000 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: References: Message-ID: <613BBDD2-A733-49BD-BF0E-D06529EB8911@live555.com> > This is an educated guess. Remember, You Have Complete Source Code. Rather than making "an educated guess", you should be able to figure out exactly what's going on. > In Cygwin the RTSPClientConnection > socket doesn't close explicitly after a TEAR. The read bitmask > in the call to select in BasicTaskScheduler remains active > and the call returns immediately by some reason which doesn't > apply to other posixes. "RTSPServer::RTSPClientSession::handleCmd_TEARDOWN()" deliberately doesn't close the "RTSPServer::RTSPClientConnection" object - on *any* OS. This is because "RTSPClientSession" and "RTSPClientConnection" objects have separate purposes, and can have separate lifetimes. E.g., it's possible, in principle, for a RTSP client to operate on more than one RTSP session (sequentially or concurrently) using the same "RTSPClientConnection" (i.e., the same TCP connection); and it's possible for a RTSP client to use multiple "RTSPClientConnection"s during the lifetime of a RTSP session (e.g., it could create (then close) a new TCP connection for each RTSP command that it sends). The "RTSPClientConnection" object gets deleted if the call to "readSocket()" in "RTSPServer::RTSPClientConnection::incomingRequestHandler1()" (line 786 of "RTSPServer.cpp) returns a value < 0 - which should happen when the remote (i.e., client) end of the TCP connection gets closed - i.e., when the RTSP client closes the TCP connection after sending the "TEARDOWN". In other words, it's not the "TEARDOWN" command that causes the "RTSPClientConnection" object to get deleted, but rather the client's closing of the TCP connection afterwards that (should be) causing the "RTSPClientConnection" object to get deleted. If, for some reason, that's not happening on your system, then you should try to figure out why. > Modifying handleCmd_TEARDOWN so that the RTSPClientSession > deletes itself and its ourClientConnection closes sockets If you insist on doing this, then DON'T modify the supplied code. Instead, subclass "RTSPServer::RTSPClientSession" and reimplement the virtual function "handleCmd_TEARDOWN()". If you modify the supplied code, then you can expect no support on this mailing list, and your modifications will be subject to the conditions of the LGPL. This is explained very clearly in the FAQ. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Feb 25 22:28:15 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Feb 2014 16:28:15 +1000 Subject: [Live-devel] Possible error after code analysis In-Reply-To: <6D82EC1FD7BDB04EA79ED1CA69EE26ED260A5E@s-giant.herent.quadrox.be> References: <132F0D84-A028-4BFF-B0B8-53B4B4EF186E@live555.com> <6D82EC1FD7BDB04EA79ED1CA69EE26ED260A5E@s-giant.herent.quadrox.be> Message-ID: Thanks. These will be fixed 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 fantasyvideo at 126.com Tue Feb 25 04:52:39 2014 From: fantasyvideo at 126.com (Tony) Date: Tue, 25 Feb 2014 20:52:39 +0800 (CST) Subject: [Live-devel] Regarding the seek and fast forward /reverse play in rtsp server In-Reply-To: References: <374f133d.2d0b4.1444504bd6e.Coremail.fantasyvideo@126.com> Message-ID: <4e3647cf.176b6.144691aacdc.Coremail.fantasyvideo@126.com> I found another problem, The seek only can work in one play request. for example, if open it by vlc and seek it at the first time, then it work. If I stop this stream, then open it again and seek, it would fail. Is there any settings to reset when new play request is comming? At 2014-02-22 09:13:32,"Ross Finlayson" wrote: I read the faq in live555 website about the trick play, it only said the four virtual functions needs to be supported. But as the result, the vlc would drop audio buffer, so I guess the fPresentationTime should be changed too? Is it right? The "presentation time" represents the time at which the media should be 'presented' (i.e., displayed or played) to a receiver. So, of course, you need to make sure that it's aligned with 'wall clock time', even if you are doing fast-forward or reverse-play. E.g., if you're doing fast-forward 2x, your server's presentation times should *not* increase 2x as fast as normal. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Wed Feb 26 16:12:19 2014 From: warren at etr-usa.com (Warren Young) Date: Wed, 26 Feb 2014 17:12:19 -0700 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: <613BBDD2-A733-49BD-BF0E-D06529EB8911@live555.com> References: <613BBDD2-A733-49BD-BF0E-D06529EB8911@live555.com> Message-ID: <530E82E3.60606@etr-usa.com> On 2/25/2014 14:33, Ross Finlayson wrote: > > The "RTSPClientConnection" object gets deleted if the call to > "readSocket()" in > "RTSPServer::RTSPClientConnection::incomingRequestHandler1()" (line 786 > of "RTSPServer.cpp) returns a value < 0 - which should happen when the > remote (i.e., client) end of the TCP connection gets closed The FreeBSD recv() page says that, but it's incomplete. It only documents > 0 and -1 returns, but there is also the possibility of a 0 return, which is a legal, distinct value. It mans the client has done a graceful disconnect. The recv() pages for Linux and Winsock fully document this behavior: http://goo.gl/zi6cGZ http://linux.die.net/man/2/recv I have verified that FreeBSD 9 behaves the same way. With a simple select() based server, select() says the socket is readable after the client gracefully disconnects, and the subsequent recv() call does get 0, not -1. I imagine if you continue calling recv() on that socket, some stacks may then return -1 (errno == ENOTCONN?) but that's because the error is in the caller, because it is calling recv() more times than necessary. I sent an email to this list on November 25 with a potential similar problem in Groupsock. From finlayson at live555.com Wed Feb 26 17:37:11 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Feb 2014 11:37:11 +1000 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: <530E82E3.60606@etr-usa.com> References: <613BBDD2-A733-49BD-BF0E-D06529EB8911@live555.com> <530E82E3.60606@etr-usa.com> Message-ID: >> The "RTSPClientConnection" object gets deleted if the call to >> "readSocket()" in >> "RTSPServer::RTSPClientConnection::incomingRequestHandler1()" (line 786 >> of "RTSPServer.cpp) returns a value < 0 - which should happen when the >> remote (i.e., client) end of the TCP connection gets closed > > The FreeBSD recv() page says that Note that I was referring to our "readSocket()" function, *not* the system "recv()"/"recvfrom()" function. Our "readSocket()" function - which is a wrapper around "recvfrom()" - returns -1 *even if* the "recvfrom()" call returns 0, for precisely the reason you mentioned. Please everybody, stop 'speculating' on imagined bugs in the code. Remember, You Have Complete Source Code. If you find a real bug, please report it (with a clear explanation of why it's a bug). But I'm not going to waste time following up on random speculation (especially if it's about something that supposedly happens only with Windows). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ELIMCO.dmartinez at navantia.es Thu Feb 27 02:29:04 2014 From: ELIMCO.dmartinez at navantia.es (=?iso-8859-1?Q?Mart=EDnez_Contador=2C_Daniel_=5BELIMCO=5D_=28CA=29?=) Date: Thu, 27 Feb 2014 10:29:04 +0000 Subject: [Live-devel] live-devel Digest, Vol 124, Issue 18 In-Reply-To: References: Message-ID: > Remember, You Have Complete Source Code. Rather than making "an educated guess", you should be able to figure out exactly what's going on. Oh, thank you, but you overstimate my ability to undertand other people's code and design decisions. > The "RTSPClientConnection" object gets deleted if the call to "readSocket()" in RTSPServer::RTSPClientConnection::incomingRequestHandler1()" (line 786 of "RTSPServer.cpp) returns a value < 0 - which should happen when the remote (i.e., client) end of the TCP connection gets closed - i.e., when the RTSP client closes the TCP connection after sending the "TEARDOWN". Well, that's not happening for me. readSocket is always returning 0. Going one level deeper, I see recvfrom in readSocket does return -1 and err 113 after the client TEARs, but the "HACK to work around bugs in Linux and Windows" makes it a zero again. Ifdef'ing the whole hack for Cygwin seems to work "with no (evident (to me)) adverse effects", making the return value -1 too, not that I'm implying that any is the best (even just a good) solution. I don't know what those bugs were, if they are in Cygwin, even if they are still present in Linux, and forgive me for wanting to avoid delving deeper in OS code. Would any of those proposals be "safe" in case Cygwin doesn't assume responsibility or take too long? Daniel Martinez Contador ELIMCO- Soluciones Integrales S.A. Navantia - Sistemas de Control Ctra. Algameca, s/n 30205 Cartagena (Murcia) Tlfo: 968 323 387 Email: elimco.dmartinez at navantia.es www.elimco.com Sorry for the disclaimer below, that's my corporate server's doing. NAVANTIA ______________________________ Este mensaje, y cualquier fichero anexo al mismo, contiene informacion de caracter confidencial dirigida exclusivamente a su(s) destinatario(s) y, en su caso, sometida a secreto profesional. Queda prohibida su difusion, copia o distribucion a terceros sin la previa autorizacion escrita. Si Vd. ha recibido este mensaje por error, se ruega lo comunique inmediatamente por esta misma via y proceda a su completa eliminacion. The information in this e-mail, and in any attachments, is confidential and, if any, protected by a professional privilege, and intended solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, copy or distribution of this information is prohibited without the prior written consent. If you have received this communication in error, please notify the sender by reply e-mail and delete it. ______________________________ From rcoker at pythagdev.com Thu Feb 27 10:30:37 2014 From: rcoker at pythagdev.com (Rob Coker) Date: Thu, 27 Feb 2014 12:30:37 -0600 Subject: [Live-devel] testRTSPClient - can't find a port not in use Message-ID: <004101cf33ea$02bb8000$08328000$@com> I am using the testRTSPClient and I am having some trouble with the bind() call in GroupsockHelper.cpp::setupDatagramSocket() on both Linux and QNX OSes using a Sabrelite board (uses iMx6 quad-core ARM processor). It is frequently trying all the ports and not being able to bind to any of the odd ports. I haven't checked Linux, but in QNX I get back the Address already in use error. Netstat doesn't show the ports being used prior to me running testRTSPClient, though. On QNX, it will frequently work for the first subsession of a session after boot. The 2nd subsession usually doesn't, but I've seen both subsessions work at least once. It's difficult to determine much rhyme or reason. I noticed that the code that calls setupDatagramSocket is trying to find sequential port numbers (even for RTP, following odd for RTSP). The trouble seems to be with the RTSP ports. I don't understand the code well enough to know whether these port numbers have to be sequential because I seem to get the even ports with no problem. Perhaps something is different about the way the socket is set up for RTSP? Thanks, Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Feb 27 16:00:52 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Feb 2014 10:00:52 +1000 Subject: [Live-devel] testRTSPClient - can't find a port not in use In-Reply-To: <004101cf33ea$02bb8000$08328000$@com> References: <004101cf33ea$02bb8000$08328000$@com> Message-ID: <2858994F-6E09-4752-9260-5C2FC823D111@live555.com> > I noticed that the code that calls setupDatagramSocket is trying to find sequential port numbers (even for RTP, following odd for RTSP). The trouble seems to be with the RTSP ports. You mean "RTCP" here, not "RTSP". But yes, it's important (for now, at least) that these port numbers be sequential (with the even port number being used for RTP, and the next (i.e., odd) port number being used for RTCP). So don't even think of modifying this code! I don't know why this is not working for you; nobody else has had problems using this code to find a pair of port numbers. So there must be something strange about your system. I suggest that you try on a more conventional Linux system (e.g., running on a desktop PC or server) first, before trying it on your board. And I suggest making sure that it's working for Linux first, before you try QNX. Apart from that I don't really have any suggestions. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Feb 27 16:19:43 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Feb 2014 10:19:43 +1000 Subject: [Live-devel] Overuse of CPU in binaries of CYGWIN In-Reply-To: References: Message-ID: <2A0D6699-CED5-411A-A488-0841D11B2B1F@live555.com> (Remember everyone - if you're responding to a message in a mailing list digest, make sure to fix the "Subject:" line in your response. (I've done it for you here.)) On Feb 27, 2014, at 8:29 PM, Mart?nez Contador, Daniel [ELIMCO] (CA) wrote: >> Remember, You Have Complete Source Code. Rather than making "an educated guess", you should be able to figure out exactly what's going on. > Oh, thank you, but you overstimate my ability to undertand other people's code and design decisions. And you overestimate my ability to spend lots of time helping people 'for free :-). But fortunately, you have been able to figure out what's going wrong for you, as you noted below: > >> The "RTSPClientConnection" object gets deleted if the call to "readSocket()" in RTSPServer::RTSPClientConnection::incomingRequestHandler1()" (line 786 of "RTSPServer.cpp) returns a value < 0 - which should happen when the remote (i.e., client) end of the TCP connection gets closed - i.e., when the RTSP client closes the TCP connection after sending the "TEARDOWN". > Well, that's not happening for me. readSocket is always returning 0. Going one level deeper, I see recvfrom in readSocket does return -1 and err 113 after the client TEARs, but the "HACK to work around bugs in Linux and Windows" makes it a zero again. That line of code was added - several years ago - to work around an alleged bug in at least some versions of Linux, whereby the call to "recvfrom()" would return 113 /*EHOSTUNREACH*/ on a *datagram* socket, which made no sense. It's not clear whether this is still an issue... > Ifdef'ing the whole hack for Cygwin seems to work "with no (evident (to me)) adverse effects", making the return value -1 too In the next release of the software I'll probably just remove this line. (If it happens to break for anyone, they'll just have to come back to us with good explanation why they think they still need it.) Thanks for tracking down what was causing the problem for you. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssingh at neurosoft.in Thu Feb 27 22:20:37 2014 From: ssingh at neurosoft.in (ssingh at neurosoft.in) Date: Fri, 28 Feb 2014 11:50:37 +0530 Subject: [Live-devel] RTMP support Message-ID: <5453dc3577ecd0e414ba24b30905511f@neurosoft.in> I am planning to use live555 to stream video and audio to flash media server. I am not sure if that is supported in live555. Can anyone please give me some direction if that is possible using live555 and how can we do that. I have used live555 to stream using RTSP protocol but not sure how can we use library to act as publisher for flash media server. -Caduceus From finlayson at live555.com Fri Feb 28 00:30:18 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Feb 2014 18:30:18 +1000 Subject: [Live-devel] RTMP support In-Reply-To: <5453dc3577ecd0e414ba24b30905511f@neurosoft.in> References: <5453dc3577ecd0e414ba24b30905511f@neurosoft.in> Message-ID: On Feb 28, 2014, at 4:20 PM, ssingh at neurosoft.in wrote: > I am planning to use live555 to stream video and audio to flash media server. I am not sure if that is supported in live555. No. RMTP is a proprietary, non-standard protocol (and, I think, patent-encumbered as well). It's unlikely that we'll ever support it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.beoldo at technoaware.com Fri Feb 28 03:22:02 2014 From: andrea.beoldo at technoaware.com (Andrea Beoldo) Date: Fri, 28 Feb 2014 12:22:02 +0100 Subject: [Live-devel] RTSP Server streaming problem: disconnect after some time Message-ID: <5310715A.1020309@technoaware.com> Hi, we have developed a RTSP video streaming server using Live555 (version 07/2011). With the same verison of Live lib we have also implemented a RTSP Client to show the stream. We use this client without any problem to acquire stream from different cameras. The problem is that with when I connect this Client to the developed streaming server (in unicast mode) the connection close after sime time (around 1 hour). The Client perform a keepalive every 30 seconds calling a sendOptionCmd(). I tried to work (on thye server side) on the reclamationTestSeconds parameters. I set it to 0 and the problem still remains. Here there is the c++ code that I used on the streaming server side: TaskScheduler* scheduler = BasicTaskScheduler::createNew(); m_pEnvironment = BasicUsageEnvironment::createNew(*scheduler); UserAuthenticationDatabase* authDB = NULL; RTSPServer* rtspServer = RTSPServer::createNew(*m_pEnvironment, params.m_iServerPort, authDB, 45); if (rtspServer == NULL) { *m_pEnvironment << "Failed to create RTSP server: " << m_pEnvironment->getResultMsg() << "\n"; return; } ServerMediaSession* sms = ServerMediaSession::createNew(*m_pEnvironment, params.m_sStreamName.c_str(), "", "Session streamed by streamer", True /*SSM*/); sms->addSubsession(serverMediaSubsession::createNew(*m_pEnvironment, true, params, this)); rtspServer->addServerMediaSession(sms); char* url = rtspServer->rtspURL(sms); *m_pEnvironment << "Play this stream using the URL \"" << url << "\"\n"; delete[] url; // Start the streaming: *m_pEnvironment << "Beginning streaming...\n"; m_initSemaphore.post(); m_pEnvironment->taskScheduler().doEventLoop(); Do you have any idea how to solve this problem? Thank you very much in advance for your help. Best regards, -- Andrea Beoldo Project Manager/R&D Technoaware Srl Corso Buenos Aires 18/11, 16129 Genova (GE) Ph. +39 010 5539239 Fax. +39 0105539240 Email: andrea.beoldo at technoaware.com Web: www.technoaware.com ------------------------------------------------------------------------ *Privacy* Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo ? consentito esclusivamente al destinatario del messaggio, per le finalit? indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio ? destinato, La invitiamo ad eliminarlo dal Suo sistema ed a distruggere le varie copie o stampe, dandocene gentilmente comunicazione. Ogni utilizzo improprio ? contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). TechnoAware opera in conformit? al D.lgs 196/2003 e alla legislazione europea. The information contained in this message as well as the attached file(s)is confidential/privileged and is only intended for the person to whom it is addressed. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, or you have received this communication in error, please be aware that any dissemination, distribution or duplication is strictly prohibited and can be illegal. Please notify us immediately and delete all copies from your mailbox and other archives. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Feb 28 15:00:50 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 1 Mar 2014 09:00:50 +1000 Subject: [Live-devel] RTSP Server streaming problem: disconnect after some time In-Reply-To: <5310715A.1020309@technoaware.com> References: <5310715A.1020309@technoaware.com> Message-ID: > we have developed a RTSP video streaming server using Live555 (version 07/2011). This is *extremely* out of date! As explained clearly in the FAQ (that you were asked to read before posting to the mailing list), we support only the latest version of the "LIVE555 Streaming Media" software: http://www.live555.com/liveMedia/faq.html#latest-version Therefore, I completely ignored the rest of your message. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: