From bbischan at watchtower-security.com Fri Nov 1 18:49:17 2013 From: bbischan at watchtower-security.com (Bob Bischan) Date: Fri, 1 Nov 2013 20:49:17 -0500 Subject: [Live-devel] doubled framerate necessary to correctly capture RTSP stream using openRTSP In-Reply-To: References: Message-ID: Almost sounds like an interlaced -vs- non-interlaced video issue... On Thu, Oct 31, 2013 at 2:07 PM, VTMusicAdmin wrote: > I am experiencing an issue with openRTSP for which I've not yet been able > to find an explanation. If there is a more appropriate forum for this or a > FAQ I have missed, please let me know. I'm attempting to use openRTSP to > capture and record the RTSP stream from an Extron SME-100 live streaming > hardware encoder. The encoder is configured with a frame rate / GOP length > of 30 fps, yet if I set openRTSP with a frame rate of 30 like this: > > openRTSP -d 300 -4 -w 640 -h 360 -f 30 -Q rtsp://URL > test.mp4 (or) > openRTSP -d 300 -q -w 640 -h 360 -f 30 -Q rtsp://URL > test.mov > > The video is the incorrect speed and does not match the audio. If > however, I set openRTSP with a frame rate of 60 with: > > openRTSP -d 300 -4 -w 640 -h 360 -f 60 -Q rtsp://URL > test.mp4 (or) > openRTSP -d 300 -q -w 640 -h 360 -f 60 -Q rtsp://URL > test.mov > > The video is captured correctly and is synchronous with the audio for the > duration of the capture. This is a perfectly viable work-around, but I'm > curious about why openRTSP only seems to work as expected when set to > capture at a 2x (actual) frame rate. Am I misunderstanding something about > the use of openRTSP or the process by any chance? Anny insight that can > be offered into this situation would be greatly appreciated; thank you! > > -- > -- Michael Dunston > -- Music and Technology > -- School of Performing Arts > -- Music | Theatre | Cinema > -- > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > ______________________________**_________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/**mailman/listinfo/live-devel > -- Bob Bischan Manager (Operations/Software Development) *WATCHTOWER SECURITY, INC.* 2418 Northline Industrial Drive Maryland Heights, MISSOURI 63043 314 427 4586 office 314 330 9001 cell 314 427 8823 fax www.watchtower-security.com *?Protecting your community and those you value most.?* -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 3 01:10:13 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 3 Nov 2013 01:10:13 -0700 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error Message-ID: <527604E5.9050402@vivint.com> I have a question in regards to the live555proxyServer. I have been playing with the server and have implemented one for our use for our project. It works great when connecting to all proxied rtsp streams, however if I wait about 10-15 seconds and than connect a client I always get a 400 Bad Request error returned to the server on a SETUP. It seems to be specific to the rtspserver I proxy. I have two sets of cameras I'm proxing, one set does not exhibit the problem where as the other does. I have played with changing the liveness value from the default of 60 secs to around 14 secs. But it really seems as if it does not matter if I lower the value. I'm guessing the server is not honoring the the fact the liveness is sending an OPTION to command to keep it alive. So in the case of getting an 400 error, what can one do to get the proxy server to reconnect to the server that is failing. I know that the camera rtsp server I'm proxing works every time from a client if I directly goto the rtsp://address of the camera, however via the proxy server it will fail if I wait too long. Thanks, Craig From finlayson at live555.com Sun Nov 3 01:32:23 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 3 Nov 2013 01:32:23 -0700 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: <527604E5.9050402@vivint.com> References: <527604E5.9050402@vivint.com> Message-ID: Please post an example of the diagnostic output from the *unmodified* proxy server, when run with the back-end server that causes you a problem. I.e., run the server with the "-V" command-line option. (And, as always, make sure you're using the most up-to-date version of the code.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 3 01:51:01 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 3 Nov 2013 02:51:01 -0700 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: References: <527604E5.9050402@vivint.com> Message-ID: <52761C85.7040808@vivint.com> Ok, so I did a quick run of the liveProxyServer. See 400 Bad Request below, this is when I connect my RTSPClient to rtsp://172.16.10.100/proxyStream (The client was gstreamer playbin2) root at custom:~# live555ProxyServer -V rtsp://172.16.10.109/live.s dp LIVE555 Proxy Server (LIVE555 Streaming Media library version 2013.10.25) Opening connection to 172.16.10.109, port 554... RTSP stream, proxying the stream "rtsp://172.16.10.109/live.sdp" Play this stream using the URL: rtsp://172.16.10.100/proxyStream (We use port 80 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://172.16.10.109/live.sdp RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.10.25) Accept: application/sdp Received 509 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Sun, 3 Nov 2013 1:43:44 GMT Content-Base: rtsp://172.16.10.109/live.sdp/ Content-Type: application/sdp Content-Length: 348 v=0 o=RTSP 1383443024 281 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 98 b=AS:0 a=rtpmap:98 H264/90000 a=control:trackID=1 a=fmtp:98 packetization-mode=1; profile-level-id=64401f; sprop-parameter-sets=J2RAH6wsagFAFumoKDAqAAAH0gAB1MAo,KO4EYsA= ProxyServerMediaSession["rtsp://172.16.10.109/live.sdp/"] added new "ProxyServerMediaSubsession" for RTP/video/H264 track Opening connection to 172.16.10.109, port 554... ...remote connection opened Sending request: OPTIONS rtsp://172.16.10.109/live.sdp/ RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.10.25) Received 143 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 3 Date: Sun, 3 Nov 2013 1:44:32 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 4232835661) Opening connection to 172.16.10.109, port 554... ProxyServerMediaSubsession["H264"]::createNewRTPSink() ...remote connection opened Sending request: SETUP rtsp://172.16.10.109/live.sdp/trackID=1 RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.10.25) Transport: RTP/AVP;unicast;client_port=60278-60279 Received 37 new bytes of response data. Received a complete SETUP response: RTSP/1.0 400 Bad Request CSeq: 4 ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 468786568) Opening connection to 172.16.10.109, port 554... ProxyServerMediaSubsession["H264"]::createNewRTPSink() ...remote connection opened Opening connection to 172.16.10.109, port 554... ...remote connection opened Sending request: OPTIONS rtsp://172.16.10.109/live.sdp/ RTSP/1.0 CSeq: 6 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.10.25) Received 143 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 6 Date: Sun, 3 Nov 2013 1:45:26 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN ----------- I was looking into the RTSPClient code and in the handleResponseBytes(), it does not a handle a 400 Bad request. Which maybe ideal when not a proxy server. However in the case of being a proxy server you would want to treat a failure such as a 400 as a disconnect (I would think) and reconnect as if the liveness responded with an error? As a test I modified handleResponseBytes() to call a virtual function that I can override in the ProxyRTSPClient to handle 400 like a disconnect. As if the continueAfterLivenessCommand() was called with a resultCode < 0. It sometimes recovers now, but it causes problems with my RTSP Client and fails too. So I wait for your guidence. Thanks, Craig On 11/03/2013 01:32 AM, Ross Finlayson wrote: Please post an example of the diagnostic output from the *unmodified* proxy server, when run with the back-end server that causes you a problem. I.e., run the server with the "-V" command-line option. (And, as always, make sure you're using the most up-to-date version of the code.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Nov 3 03:24:59 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 3 Nov 2013 03:24:59 -0800 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: <52761C85.7040808@vivint.com> References: <527604E5.9050402@vivint.com> <52761C85.7040808@vivint.com> Message-ID: <04786D0B-3D50-4F0D-8384-6CBE6CEE14C4@live555.com> > Sending request: SETUP rtsp://172.16.10.109/live.sdp/trackID=1 RTSP/1.0 > CSeq: 4 > User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.10.25) > Transport: RTP/AVP;unicast;client_port=60278-60279 > > > Received 37 new bytes of response data. > Received a complete SETUP response: > RTSP/1.0 400 Bad Request > CSeq: 4 OK, so there appears to be a bug in the back-end server. You will need to contact the manufacturer of this server, and ask them to fix this bug. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbischan at watchtower-security.com Sun Nov 3 08:58:42 2013 From: bbischan at watchtower-security.com (Bob Bischan) Date: Sun, 3 Nov 2013 10:58:42 -0600 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: <527604E5.9050402@vivint.com> References: <527604E5.9050402@vivint.com> Message-ID: Be sure to read changelog.txt for recent updates/changes to ProxyServer implementation. I have been testing ProxyServer with numerous streams / client connections with success. Bob On Sun, Nov 3, 2013 at 2:10 AM, Craig Matsuura wrote: > I have a question in regards to the live555proxyServer. I have been > playing with the server and have implemented one for our use for our > project. It works great when connecting to all proxied rtsp streams, > however if I wait about 10-15 seconds and than connect a client I always > get a 400 Bad Request error returned to the server on a SETUP. > > It seems to be specific to the rtspserver I proxy. I have two sets of > cameras I'm proxing, one set does not exhibit the problem where as the > other does. I have played with changing the liveness value from the > default of 60 secs to around 14 secs. But it really seems as if it does > not matter if I lower the value. I'm guessing the server is not > honoring the the fact the liveness is sending an OPTION to command to > keep it alive. > > So in the case of getting an 400 error, what can one do to get the proxy > server to reconnect to the server that is failing. I know that the > camera rtsp server I'm proxing works every time from a client if I > directly goto the rtsp://address of the camera, however via the proxy > server it will fail if I wait too long. > > Thanks, > Craig > _______________________________________________ > 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 cmatsuura at vivint.com Sun Nov 3 12:11:24 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 3 Nov 2013 13:11:24 -0700 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: References: <527604E5.9050402@vivint.com> Message-ID: <5276ADEC.4020008@vivint.com> I have read the readme, but thanks for the suggestion,. I have had success with several as well, but I have one particular camera with this issue. I was hoping there was a good way to handle this from the live555 side. Sometimes camera manufactures are slow to respond. Thanks, Craig On 11/03/2013 09:58 AM, Bob Bischan wrote: Be sure to read changelog.txt for recent updates/changes to ProxyServer implementation. I have been testing ProxyServer with numerous streams / client connections with success. Bob On Sun, Nov 3, 2013 at 2:10 AM, Craig Matsuura > wrote: I have a question in regards to the live555proxyServer. I have been playing with the server and have implemented one for our use for our project. It works great when connecting to all proxied rtsp streams, however if I wait about 10-15 seconds and than connect a client I always get a 400 Bad Request error returned to the server on a SETUP. It seems to be specific to the rtspserver I proxy. I have two sets of cameras I'm proxing, one set does not exhibit the problem where as the other does. I have played with changing the liveness value from the default of 60 secs to around 14 secs. But it really seems as if it does not matter if I lower the value. I'm guessing the server is not honoring the the fact the liveness is sending an OPTION to command to keep it alive. So in the case of getting an 400 error, what can one do to get the proxy server to reconnect to the server that is failing. I know that the camera rtsp server I'm proxing works every time from a client if I directly goto the rtsp://address of the camera, however via the proxy server it will fail if I wait too long. Thanks, Craig _______________________________________________ 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 cmatsuura at vivint.com Sun Nov 3 12:15:18 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 3 Nov 2013 13:15:18 -0700 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: <04786D0B-3D50-4F0D-8384-6CBE6CEE14C4@live555.com> References: <527604E5.9050402@vivint.com> <52761C85.7040808@vivint.com> <04786D0B-3D50-4F0D-8384-6CBE6CEE14C4@live555.com> Message-ID: <5276AED6.10608@vivint.com> Hi Ross, That is what I suspect as well, however I was trying to recover from such an error as it would be nice to be more robust and not fail because of a firmware issue with the camera. I am in the process of having the manufacture look into the issue, however this can be a slow process. I was hoping to be more robust on my side with the live555 and handle such errors. I started to make changes to recover from the 400 error but have a few things to fix as my rtspclient fails after the force restart in the ProxyRTSPClient. If I can solve this I can make our side more robust to failures on camera sources. Thanks, Craig On 11/03/2013 04:24 AM, Ross Finlayson wrote: Sending request: SETUP rtsp://172.16.10.109/live.sdp/trackID=1 RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.10.25) Transport: RTP/AVP;unicast;client_port=60278-60279 Received 37 new bytes of response data. Received a complete SETUP response: RTSP/1.0 400 Bad Request CSeq: 4 OK, so there appears to be a bug in the back-end server. You will need to contact the manufacturer of this server, and ask them to fix this bug. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 3 12:20:36 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 3 Nov 2013 13:20:36 -0700 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: References: <527604E5.9050402@vivint.com> Message-ID: <5276B014.8020708@vivint.com> Hi Bob, I was looking at some post you had and wondering if my issues is related. http://lists.live555.com/pipermail/live-devel/2013-October/017538.html So if I read correctly the OPTION command, needs an additional Session field to keep your axis camera alive? Was this code in the 20131025 sources? Thanks, Craig On 11/03/2013 09:58 AM, Bob Bischan wrote: Be sure to read changelog.txt for recent updates/changes to ProxyServer implementation. I have been testing ProxyServer with numerous streams / client connections with success. Bob On Sun, Nov 3, 2013 at 2:10 AM, Craig Matsuura > wrote: I have a question in regards to the live555proxyServer. I have been playing with the server and have implemented one for our use for our project. It works great when connecting to all proxied rtsp streams, however if I wait about 10-15 seconds and than connect a client I always get a 400 Bad Request error returned to the server on a SETUP. It seems to be specific to the rtspserver I proxy. I have two sets of cameras I'm proxing, one set does not exhibit the problem where as the other does. I have played with changing the liveness value from the default of 60 secs to around 14 secs. But it really seems as if it does not matter if I lower the value. I'm guessing the server is not honoring the the fact the liveness is sending an OPTION to command to keep it alive. So in the case of getting an 400 error, what can one do to get the proxy server to reconnect to the server that is failing. I know that the camera rtsp server I'm proxing works every time from a client if I directly goto the rtsp://address of the camera, however via the proxy server it will fail if I wait too long. Thanks, Craig _______________________________________________ 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 bbischan at watchtower-security.com Sun Nov 3 13:59:55 2013 From: bbischan at watchtower-security.com (Bob Bischan) Date: Sun, 3 Nov 2013 15:59:55 -0600 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: <5276B014.8020708@vivint.com> References: <527604E5.9050402@vivint.com> <5276B014.8020708@vivint.com> Message-ID: Yes...that was added in 2013.10.16 version. In my case this took care of the problem with streams timing out. Bob On Sun, Nov 3, 2013 at 2:20 PM, Craig Matsuura wrote: > Hi Bob, > > I was looking at some post you had and wondering if my issues is related. > > http://lists.live555.com/pipermail/live-devel/2013-October/017538.html > > So if I read correctly the OPTION command, needs an additional Session > field to keep your axis camera > alive? Was this code in the 20131025 sources? > > > Thanks, > Craig > > On 11/03/2013 09:58 AM, Bob Bischan wrote: > > Be sure to read changelog.txt for recent updates/changes to ProxyServer > implementation. I have been testing ProxyServer with numerous streams / > client connections with success. > > Bob > > On Sun, Nov 3, 2013 at 2:10 AM, Craig Matsuura wrote: > >> I have a question in regards to the live555proxyServer. I have been >> playing with the server and have implemented one for our use for our >> project. It works great when connecting to all proxied rtsp streams, >> however if I wait about 10-15 seconds and than connect a client I always >> get a 400 Bad Request error returned to the server on a SETUP. >> >> It seems to be specific to the rtspserver I proxy. I have two sets of >> cameras I'm proxing, one set does not exhibit the problem where as the >> other does. I have played with changing the liveness value from the >> default of 60 secs to around 14 secs. But it really seems as if it does >> not matter if I lower the value. I'm guessing the server is not >> honoring the the fact the liveness is sending an OPTION to command to >> keep it alive. >> >> So in the case of getting an 400 error, what can one do to get the proxy >> server to reconnect to the server that is failing. I know that the >> camera rtsp server I'm proxing works every time from a client if I >> directly goto the rtsp://address of the camera, however via the proxy >> server it will fail if I wait too long. >> >> Thanks, >> Craig >> _______________________________________________ >> live-devel mailing list >> live-devel at lists.live555.com >> http://lists.live555.com/mailman/listinfo/live-devel > > > > _______________________________________________ > 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 Nov 3 14:05:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 3 Nov 2013 14:05:09 -0800 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: References: <527604E5.9050402@vivint.com> <5276B014.8020708@vivint.com> Message-ID: <7AAEE68F-440B-454D-82DA-069AC785AD18@live555.com> Craig was running an up-to-date version of the code. The problem is definitely with his 'back-end' server; it should not be returning a "400 Bad Request" error in response to a perfectly good request. This server (network camera) needs to be fixed (perhaps a firmware upgrade is available?). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 3 14:50:51 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 3 Nov 2013 15:50:51 -0700 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: <7AAEE68F-440B-454D-82DA-069AC785AD18@live555.com> References: <527604E5.9050402@vivint.com> <5276B014.8020708@vivint.com> <7AAEE68F-440B-454D-82DA-069AC785AD18@live555.com> Message-ID: <5276D34B.7000708@vivint.com> Thanks Ross, I have an email out to the camera provider and told them to get on the list. Sounds like you work with alot of camera manufactures. This particular camera is a Vivotek, anyone from there company on this list? Thanks, Craig On 11/03/2013 03:05 PM, Ross Finlayson wrote: Craig was running an up-to-date version of the code. The problem is definitely with his 'back-end' server; it should not be returning a "400 Bad Request" error in response to a perfectly good request. This server (network camera) needs to be fixed (perhaps a firmware upgrade is available?). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Mon Nov 4 01:56:25 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Mon, 4 Nov 2013 10:56:25 +0100 Subject: [Live-devel] Matroska BANK_SIZE overflow In-Reply-To: References: <31396_1383153571_52713FA3_31396_3808_1_1BE8971B6CFF3A4F97AF4011882AA25501563E9ED5C5@THSONEA01CMS01P.one.grp> Message-ID: <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> Hi Ross, I posted the file at this URL http://dl.free.fr/qPp4PZMIV 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? : mercredi 30 octobre 2013 20:02 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Matroska BANK_SIZE overflow I reach this limit parsing an MKV file with an H264 stream. So please put this file on a (publically-accessible) web server, and send us the URL, so we can download and test it for ourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 4 06:09:40 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 4 Nov 2013 06:09:40 -0800 Subject: [Live-devel] Matroska BANK_SIZE overflow In-Reply-To: <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> References: <31396_1383153571_52713FA3_31396_3808_1_1BE8971B6CFF3A4F97AF4011882AA25501563E9ED5C5@THSONEA01CMS01P.one.grp> <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> Message-ID: <837A6C91-8E03-42C2-8CDB-503757429C73@live555.com> > I posted the file at this URL http://dl.free.fr/qPp4PZMIV I had no problem streaming this ".mkv" file - using either "testOnDemandRTSPServer" or the "LIVE555 Media Server". How are you parsing/demultiplexing this Matroska file? Are you using your own application (that presumably uses the API in "liveMedia/include/MatroskaFile.hh")? If so, then please the code for a simple application (as simple as you can make it) that reproduces this problem when parsing/demultiplexing this Matroska file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 4 09:25:30 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 4 Nov 2013 09:25:30 -0800 Subject: [Live-devel] Matroska BANK_SIZE overflow In-Reply-To: <837A6C91-8E03-42C2-8CDB-503757429C73@live555.com> References: <31396_1383153571_52713FA3_31396_3808_1_1BE8971B6CFF3A4F97AF4011882AA25501563E9ED5C5@THSONEA01CMS01P.one.grp> <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> <837A6C91-8E03-42C2-8CDB-503757429C73@live555.com> Message-ID: <8476DB13-01FA-4DD4-9C22-B722F391A756@live555.com> Adding a missing word to my previous answer: > How are you parsing/demultiplexing this Matroska file? Are you using your own application (that presumably uses the API in "liveMedia/include/MatroskaFile.hh")? If so, then please [provide] the code for a simple application (as simple as you can make it) that reproduces this problem when parsing/demultiplexing this Matroska file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Mon Nov 4 09:53:41 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Mon, 4 Nov 2013 10:53:41 -0700 Subject: [Live-devel] Fwd: Re: Proxy Server rtsperver timeout with 400 error In-Reply-To: <5277DD16.10304@gmail.com> References: <527795D8.1070302@gmail.com> <5277CF12.4060904@gmail.com> <5277D279.4020608@vivint.com> <5277D4F7.4080106@gmail.com> <5277D834.5090805@vivint.com> <5277DD16.10304@gmail.com> Message-ID: <5277DF25.40703@vivint.com> I'm no expert in RTSP, but from reading the code and observing logs I could see what the proxy server is doing. Thanks, Craig On 11/04/2013 10:44 AM, Pawel Gorazda wrote: > Exactly, issuing PLAY causes SETUP and if do it before proxy > sends OPTIONS you are happy :). I use vlc command line to deal with it, > just for a while. > > I have same problem with IP8336W, FD8131, so you can test whether > workaround works for you. > > And regarding keep alives - I am not RTSP and live555 expert > but probably your are right - have to dig sources and rfcs before. > I plan do make same extensions to live proxy, just one switch > to avoid OPTIONS before first client connects to proxy > > Pawel > > But I am not happy to use such a workaround > On 04.11.2013 18:24, Craig Matsuura wrote: >> 520IR >> 720W >> >> So your issuing a play before a setup? >> >> The scenario that fails is a OPTIONS command before SETUP. So playing >> before causes a SETUP, PLAY command?. Is it the liveness timer sending >> the OPTIONS or an actual OPTIONS command being issued to get OPTIONS and >> not keep the connection alive. >> >> Thanks, >> Craig >> >> On 11/04/2013 10:10 AM, Pawel Gorazda wrote: >>> Craig, >>> >>> my workaround is to connect to proxy server just after it starts, >>> issue PLAY and then all works fine. I do not need patch at this moment >>> but will inform you and send when will be ready. Have to dig Ross's >>> sources a bit more before. What model of vivotek do you have? >>> >>> Pawel >>> >>> On 04.11.2013 17:59, Craig Matsuura wrote: >>>> Pawel, >>>> >>>> What did you do to fix the problem? Did you modify the >>>> ProxyServerMediaSession.cpp? Can you send me a patch of what you did? >>>> >>>> Thanks, >>>> Craig >>>> >>>> >>>> On 11/04/2013 09:45 AM, Pawel Gorazda wrote: >>>>> Maybe help you, I don't see on list-devel so send you directly >>>>> >>>>> Have a nice day >>>>> Pawel >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: [Live-devel] Proxy Server rtsperver timeout with 400 error >>>>> Date: Mon, 04 Nov 2013 13:40:56 +0100 >>>>> From: Pawel Gorazda >>>>> To: live-devel at lists.live555.com >>>>> >>>>> Hello Craig, >>>>> >>>>> I have same issue with vivotek, the problem is vivotek cameras does not >>>>> like OPTIONS before SETUP. >>>>> >>>>> Pawel >>>>> >>>>> On 03.11.2013 23:50, Craig Matsuura wrote: >>>>>> Thanks Ross, >>>>>> >>>>>> I have an email out to the camera provider and told them to get on the >>>>>> list. Sounds like you work with alot of camera manufactures. This >>>>>> particular camera is a Vivotek, anyone from there company on this list? >>>>>> >>>>>> Thanks, >>>>>> Craig >>>>>> >>>>>> On 11/03/2013 03:05 PM, Ross Finlayson wrote: >>>>>>> Craig was running an up-to-date version of the code. >>>>>>> >>>>>>> The problem is definitely with his 'back-end' server; it should not be >>>>>>> returning a "400 Bad Request" error in response to a perfectly good >>>>>>> request. This server (network camera) needs to be fixed (perhaps a >>>>>>> firmware upgrade is available?). >>>>>>> >>>>>>> >>>>>>> Ross Finlayson >>>>>>> Live Networks, Inc. >>>>>>> http://www.live555.com/ >>>>>>> >>>>>> _______________________________________________ >>>>>> live-devel mailing list >>>>>> live-devel at lists.live555.com >>>>>> http://lists.live555.com/mailman/listinfo/live-devel >>>>>> From finlayson at live555.com Mon Nov 4 10:08:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 4 Nov 2013 10:08:06 -0800 Subject: [Live-devel] Proxy Server rtsperver timeout with 400 error In-Reply-To: <5277DF25.40703@vivint.com> References: <527795D8.1070302@gmail.com> <5277CF12.4060904@gmail.com> <5277D279.4020608@vivint.com> <5277D4F7.4080106@gmail.com> <5277D834.5090805@vivint.com> <5277DD16.10304@gmail.com> <5277DF25.40703@vivint.com> Message-ID: >> I plan do make same extensions to live proxy, just one switch >> to avoid OPTIONS before first client connects to proxy FYI, the problem with doing this would be that - if there is a long delay before the first client connects to the proxy - the connection to the back-end server might end up timing out. The whole purpose of sending the periodic "OPTIONS" commands is to ensure the back-end server that the proxy is still alive, so that it doesn't time out the connection. In any case, though, this whole discussion is moot, because I absolutely WILL NOT be spending any time/effort to 'work around' this bug in Vivotek cameras unless we hear *directly* from Vivotek (i.e., not just through some intermediary), explaining themselves. So please don't bother responding anymore to this thread (unless you're Vivotek). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb.dotnet at gmail.com Mon Nov 4 13:06:10 2013 From: tayeb.dotnet at gmail.com (Tayeb Meftah) Date: Mon, 4 Nov 2013 22:06:10 +0100 Subject: [Live-devel] Vod Playlist anounce Message-ID: <521A78F685844BA99B9D12FC196FA812@worksc08f920f1> hi guys is it pocible to use Live555 RTSP server to anounce my movie's through SAP and let my local clients discover it? thank Tayeb Meftah Voice of the blind T Broadcast Freedom http://www.vobradio.org Phone:447559762242 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 4 16:53:19 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 4 Nov 2013 16:53:19 -0800 Subject: [Live-devel] Vod Playlist anounce In-Reply-To: <521A78F685844BA99B9D12FC196FA812@worksc08f920f1> References: <521A78F685844BA99B9D12FC196FA812@worksc08f920f1> Message-ID: > is it pocible to use Live555 RTSP server to anounce my movie's through SAP and let my local clients discover it? No; our RTSP server implementation does not use SAP at all. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssingh at neurosoft.in Mon Nov 4 18:37:22 2013 From: ssingh at neurosoft.in (ssingh at neurosoft.in) Date: Tue, 05 Nov 2013 08:07:22 +0530 Subject: [Live-devel] Audio timestamping issue Message-ID: <11546d901c73d447d93197cce24157f0@neurosoft.in> Hi, I implemented a device source with Ross's help and made it to work. Now I am getting nice video but my audio is choppy and is not good. So my question is what is the right way of timestamping audio and video. I read that if your source is live than no need to set fFrameDurationInMicroSeconds and you can just give getTimeOfDay() as fPresentationTime. In my case I am using FFMpeg to encode a live stream into MPEG4 and AC3 and then streaming it using live555. Should I be sending the frame with gettimeofday() as presentation time. My understanding is that we need to calculate delta between frames and set the timestamping as it is possible that encoder can give 2 consecutive frames in short duration and may be take longer for 3rd packet. With just gettimeofday() set my audio is choppy on VLC and I can see VLC dropping packets because of wrong presentation time. -C From finlayson at live555.com Mon Nov 4 20:44:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 4 Nov 2013 20:44:55 -0800 Subject: [Live-devel] Audio timestamping issue In-Reply-To: <11546d901c73d447d93197cce24157f0@neurosoft.in> References: <11546d901c73d447d93197cce24157f0@neurosoft.in> Message-ID: <56BB94E0-BCEB-4448-96C7-CB54BD639BD8@live555.com> > I implemented a device source with Ross's help and made it to work. Now I am getting nice video but my audio is choppy and is not good. So my question is what is the right way of timestamping audio and video. I read that if your source is live than no need to set fFrameDurationInMicroSeconds That's correct. Because you are streaming from a live source, you shouldn't set "fDurationInMicroseconds" (sic). > In my case I am using FFMpeg to encode a live stream into MPEG4 and AC3 and then streaming it using live555. Should I be sending the frame with gettimeofday() as presentation time. My understanding is that we need to calculate delta between frames and set the timestamping as it is possible that encoder can give 2 consecutive frames in short duration and may be take longer for 3rd packet. The presentation times - for both audio and video frames - should correspond to the times that the frames were *generated*. This is to ensure that when the receiver gets the incoming audio and video frames, it can feed them to the decoder at the appropriate time, so that audio and video will be properly synced. So, if your audio frames come in 'bunches', then you shouldn't just call "gettimeofday()" each time. Instead, think about the times that the audio (and video) frames were really *generated*, and set appropriate presentation times for each. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Tue Nov 5 05:36:06 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Tue, 5 Nov 2013 14:36:06 +0100 Subject: [Live-devel] Matroska BANK_SIZE overflow In-Reply-To: <8476DB13-01FA-4DD4-9C22-B722F391A756@live555.com> References: <31396_1383153571_52713FA3_31396_3808_1_1BE8971B6CFF3A4F97AF4011882AA25501563E9ED5C5@THSONEA01CMS01P.one.grp> <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> <837A6C91-8E03-42C2-8CDB-503757429C73@live555.com> <8476DB13-01FA-4DD4-9C22-B722F391A756@live555.com> Message-ID: <15978_1383658567_5278F447_15978_894_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB21FF4@THSONEA01CMS01P.one.grp> Hi Ross, Surely I badly use the matroska parser... What I was trying to do is to connect each matroska subsession to a sink. In fact I don't need ServerMediaSession, it is just to get the FramedSource corresponding to a subsession. The following code seem to works with some mkv but produce an overflow of BANK_SIZE with the file I send previously #include "liveMedia.hh" #include "BasicUsageEnvironment.hh" static char newMatroskaDemuxWatchVariable; static MatroskaFileServerDemux* demux; static void onMatroskaDemuxCreation(MatroskaFileServerDemux* newDemux, void* /*clientData*/) { demux = newDemux; newMatroskaDemuxWatchVariable = 1; } int main(int argc, char** argv) { TaskScheduler* scheduler = BasicTaskScheduler::createNew(); UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler); // A Matroska ('.mkv') file, with video+audio+subtitle streams: { char const* inputFileName = "test.mkv"; ServerMediaSession* sms = ServerMediaSession::createNew(*env, inputFileName, inputFileName,inputFileName); newMatroskaDemuxWatchVariable = 0; MatroskaFileServerDemux::createNew(*env, inputFileName, onMatroskaDemuxCreation, NULL); env->taskScheduler().doEventLoop(&newMatroskaDemuxWatchVariable); ServerMediaSubsession* smss = NULL; unsigned fileSinkBufferSize = 100000; while ((smss = demux->newServerMediaSubsession()) != NULL) { sms->addSubsession(smss); MediaSource* source = demux->newDemuxedTrack(0,smss->trackNumber()); MediaSink* sink = FileSink::createNew(*env, smss->trackId(),fileSinkBufferSize, False); sink->startPlaying(*source,NULL,NULL); } } env->taskScheduler().doEventLoop(); return 0; } Thanks for your help. 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? : lundi 4 novembre 2013 18:26 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Matroska BANK_SIZE overflow Adding a missing word to my previous answer: How are you parsing/demultiplexing this Matroska file? Are you using your own application (that presumably uses the API in "liveMedia/include/MatroskaFile.hh")? If so, then please [provide] the code for a simple application (as simple as you can make it) that reproduces this problem when parsing/demultiplexing this Matroska file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 5 20:45:08 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Nov 2013 20:45:08 -0800 Subject: [Live-devel] Matroska BANK_SIZE overflow In-Reply-To: <15978_1383658567_5278F447_15978_894_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB21FF4@THSONEA01CMS01P.one.grp> References: <31396_1383153571_52713FA3_31396_3808_1_1BE8971B6CFF3A4F97AF4011882AA25501563E9ED5C5@THSONEA01CMS01P.one.grp> <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> <837A6C91-8E03-42C2-8CDB-503757429C73@live555.com> <8476DB13-01FA-4DD4-9C22-B722F391A756@live555.com> <15978_1383658567_5278F447_15978_894_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB21FF4@THSONEA01CMS01P.one.grp> Message-ID: > Surely I badly use the matroska parser? > What I was trying to do is to connect each matroska subsession to a sink. In fact I don?t need ServerMediaSession, it is just to get the FramedSource corresponding to a subsession. The "MatroskaFileServerDemux" class should be used only within a RTSP server, in which case you don't 'play' the demultiplexed tracks directly; instead, this is done indirectly, via the RTSP server implementation. I'm not sure exactly why the BANK_SIZE error was occurring for your application, but it turns out that you weren't using the API in the intended way. If you want to demultiplex the tracks from a Matroska file directly - without a RTSP server - then you can do this; however, the API didn't make this clear. That was my fault. To fix this, I have installed a new version (2013.11.06) of the "LIVE555 Streaming Media" code that improves and clarifies the API for demultiplexing a Matroska file. The following is a version of your demo application that uses the new, cleaned-up API to demultiplex a Matroska file into files for its constituent tracks. (When I run this, I don't get the BANK_SIZE error.) /////////////////////////// #include "liveMedia.hh" #include "BasicUsageEnvironment.hh" static char newMatroskaFileWatchVariable = 0; static MatroskaFile* matroskaFile; static void onMatroskaFileCreation(MatroskaFile* newFile, void* /*clientData*/) { matroskaFile = newFile; newMatroskaFileWatchVariable = 1; } int main(int argc, char** argv) { TaskScheduler* scheduler = BasicTaskScheduler::createNew(); UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler); // Open a Matroska file: char const* inputFileName = "test.mkv"; MatroskaFile::createNew(*env, inputFileName, onMatroskaFileCreation, NULL); env->taskScheduler().doEventLoop(&newMatroskaFileWatchVariable); // Create a demultiplexor from the file: MatroskaDemux* demux = matroskaFile->newDemux(); // And start copying each track: unsigned const fileSinkBufferSize = 300000; while (1) { unsigned trackNumber; FramedSource* trackSource = demux->newDemuxedTrack(trackNumber); if (trackSource == NULL) break; // For reference, display information about each track: MatroskaTrack* trackInfo = matroskaFile->lookup(trackNumber); fprintf(stderr, "Reading track %d, codec: %s\n", trackNumber, trackInfo->codecID); char outFileName[100]; sprintf(outFileName, "track%d", trackNumber); MediaSink* sink = FileSink::createNew(*env, outFileName, fileSinkBufferSize, False); sink->startPlaying(*trackSource,NULL,NULL); } env->taskScheduler().doEventLoop(); return 0; } Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.ferguson at cubitech.co.uk Wed Nov 6 01:26:23 2013 From: ken.ferguson at cubitech.co.uk (Ken Ferguson) Date: Wed, 06 Nov 2013 09:26:23 +0000 Subject: [Live-devel] QuickTime and RTCP RR packets. Message-ID: <527A0B3F.1090204@cubitech.co.uk> Hi all, I believe I am running into a known issue with QuickTime on the Mac. And I know this isn't a QuickTime mailing list but please bear with me. The issue I am seeing is that when QuickTime uses RTSP-over-HTTP it appears not to send RTCP Receiver Report packets. With the predictable result that after 65 seconds Live555 terminates the session for inactivity. A quick google search has revealed the following post made in the Apple mailing lists (back in 2007): Thanks to Dave Singer and colleagues at Apple for tracking down this issue. It turns out that QuickTime Player does, indeed, have a bug that causes it to - in some circumstances - not send out RTCP "RR" packets. Fortunately RTSP servers can work around this bug by ensuring that they always include a "source=" parameter in the response to each RTSP "SETUP" command. According to the RTSP specification, this parameter is optional, but - if present - it will not trigger the QuickTime Player bug As far as I can tell Live555 *is* sending the "source=" parameter (I've seen it in a Wireshark trace), so in theory I should be avoiding the QuickTime bug. I'm using a recent version of Live555 (2013.10.25) and trying to play a stream with QuickTime Player (v10.1). Could anyone confirm that this workaround is still valid? Or indeed is there anything else I should be doing? I'd just like to get my facts straight before submitting a bug to Apple. Kind Regards, Ken Ferguson. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 6 03:17:20 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Nov 2013 03:17:20 -0800 Subject: [Live-devel] QuickTime and RTCP RR packets. In-Reply-To: <527A0B3F.1090204@cubitech.co.uk> References: <527A0B3F.1090204@cubitech.co.uk> Message-ID: > The issue I am seeing is that when QuickTime uses RTSP-over-HTTP it appears not to send RTCP Receiver Report packets. Yes, this is a bug with QuickTime Player; it's separate from the bug that I noted back in 2007, and occurs only if RTSP-over-HTTP streaming is being used. You can try submitting a bug to Apple (I already informed a colleague high up in Apple about this problem, back in January 2013), but I wouldn't hold my breath waiting for them to fix this, as QuickTime Player does not appear to be a priority for Apple these days. Instead, I suggest using VLC as a client (it has an option (Preferences->Interface->Show All->Demuxers->RTP/RTSP) that tells it to request RTSP-over-HTTP streaming). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.ferguson at cubitech.co.uk Wed Nov 6 04:20:38 2013 From: ken.ferguson at cubitech.co.uk (Ken Ferguson) Date: Wed, 06 Nov 2013 12:20:38 +0000 Subject: [Live-devel] QuickTime and RTCP RR packets. In-Reply-To: References: <527A0B3F.1090204@cubitech.co.uk> Message-ID: <527A3416.8070905@cubitech.co.uk> >> The issue I am seeing is that when QuickTime uses RTSP-over-HTTP it appears not to send RTCP Receiver Report packets. > > Yes, this is a bug with QuickTime Player; it's separate from the bug that I noted back in 2007, and occurs only if RTSP-over-HTTP streaming is being used. > > You can try submitting a bug to Apple (I already informed a colleague high up in Apple about this problem, back in January 2013), but I wouldn't hold my breath waiting for them to fix this, as QuickTime Player does not appear to be a priority for Apple these days. > > Instead, I suggest using VLC as a client (it has an option (Preferences->Interface->Show All->Demuxers->RTP/RTSP) that tells it to request RTSP-over-HTTP streaming). > Hi Ross, Thank you for the swift reply. It's good to know at least. I will at least submit a bug to Apple about it. One can only hope that one day it will get fixed. I've already tested with VLC and confirmed that it works. Unfortunately however it isn't an option at the moment as we're actually using the QuickTime plugin in a web browser and would prefer not to use anything else simply because of it's installed base. I guess that's a decision we may have to revisit :) Thanks again, Ken. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Wed Nov 6 06:37:02 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Wed, 6 Nov 2013 15:37:02 +0100 Subject: [Live-devel] Matroska BANK_SIZE overflow In-Reply-To: References: <31396_1383153571_52713FA3_31396_3808_1_1BE8971B6CFF3A4F97AF4011882AA25501563E9ED5C5@THSONEA01CMS01P.one.grp> <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> <837A6C91-8E03-42C2-8CDB-503757429C73@live555.com> <8476DB13-01FA-4DD4-9C22-B722F391A756@live555.com> <15978_1383658567_5278F447_15978_894_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB21FF4@THSONEA01CMS01P.one.grp> Message-ID: <2817_1383748623_527A540F_2817_7522_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB95A45@THSONEA01CMS01P.one.grp> Hi Ross, This is clearer like this. Thank a lot. 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? : mercredi 6 novembre 2013 05:45 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Matroska BANK_SIZE overflow Surely I badly use the matroska parser... What I was trying to do is to connect each matroska subsession to a sink. In fact I don't need ServerMediaSession, it is just to get the FramedSource corresponding to a subsession. The "MatroskaFileServerDemux" class should be used only within a RTSP server, in which case you don't 'play' the demultiplexed tracks directly; instead, this is done indirectly, via the RTSP server implementation. I'm not sure exactly why the BANK_SIZE error was occurring for your application, but it turns out that you weren't using the API in the intended way. If you want to demultiplex the tracks from a Matroska file directly - without a RTSP server - then you can do this; however, the API didn't make this clear. That was my fault. To fix this, I have installed a new version (2013.11.06) of the "LIVE555 Streaming Media" code that improves and clarifies the API for demultiplexing a Matroska file. The following is a version of your demo application that uses the new, cleaned-up API to demultiplex a Matroska file into files for its constituent tracks. (When I run this, I don't get the BANK_SIZE error.) /////////////////////////// #include "liveMedia.hh" #include "BasicUsageEnvironment.hh" static char newMatroskaFileWatchVariable = 0; static MatroskaFile* matroskaFile; static void onMatroskaFileCreation(MatroskaFile* newFile, void* /*clientData*/) { matroskaFile = newFile; newMatroskaFileWatchVariable = 1; } int main(int argc, char** argv) { TaskScheduler* scheduler = BasicTaskScheduler::createNew(); UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler); // Open a Matroska file: char const* inputFileName = "test.mkv"; MatroskaFile::createNew(*env, inputFileName, onMatroskaFileCreation, NULL); env->taskScheduler().doEventLoop(&newMatroskaFileWatchVariable); // Create a demultiplexor from the file: MatroskaDemux* demux = matroskaFile->newDemux(); // And start copying each track: unsigned const fileSinkBufferSize = 300000; while (1) { unsigned trackNumber; FramedSource* trackSource = demux->newDemuxedTrack(trackNumber); if (trackSource == NULL) break; // For reference, display information about each track: MatroskaTrack* trackInfo = matroskaFile->lookup(trackNumber); fprintf(stderr, "Reading track %d, codec: %s\n", trackNumber, trackInfo->codecID); char outFileName[100]; sprintf(outFileName, "track%d", trackNumber); MediaSink* sink = FileSink::createNew(*env, outFileName, fileSinkBufferSize, False); sink->startPlaying(*trackSource,NULL,NULL); } env->taskScheduler().doEventLoop(); return 0; } Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at m2mservices.mobi Thu Nov 7 05:21:59 2013 From: info at m2mservices.mobi (info at m2mservices.mobi) Date: Thu, 7 Nov 2013 13:21:59 +0000 Subject: [Live-devel] Handling a change of codec midstream Message-ID: Hi Ross, I am up against an unusual problem and I am wondering if Live555 will be able to handle it. The VideoEdge NVR has various throttling capabilities when streaming to a remote client. If the source camera broadcasts in MPEG4 or Motion JPEG and the throttling is enabled the NVR will transcode the source codec to H264 video during the broadcast. The server uses an ANNOUNCE command to notify the client that this transcode about to take place. The change in Payload would cause an error normally - do you think it is possible for Live555 to be adjusted to handle this payload change mid stream? Regards Aidan Gallagher -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Nov 7 06:54:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 7 Nov 2013 06:54:05 -0800 Subject: [Live-devel] Handling a change of codec midstream In-Reply-To: References: Message-ID: <9F45A2E8-E617-4064-AEDE-01EC15E1D106@live555.com> > The server uses an ANNOUNCE command to notify the client that this transcode about to take place. Wow - this is a very obscure feature of the RTSP protocol: sending an "ANNOUNCE" command from the server to the client. This is the first time that I have ever heard of a server that does this. (Note, BTW, that the "ANNOUNCE" command - because it was poorly specified and rarely used - has been removed entirely from the proposed "RTSP 2.0" update to RTSP.) > The change in Payload would cause an error normally - do you think it is possible for Live555 to be adjusted to handle this payload change mid stream? Yes, conceivably. However, adding support for a feature like this is not something that we would do for free. If anyone (e.g., American Dynamics, which manufacturers the "VideoEdge NVR") is interested in paying for this, please let me know (by separate email). Also, you didn't say anything about which client application (using the "LIVE555 Streaming Media" code) you are using. Note that even if our library were updated to support this obscure server->client "ANNOUNCE" command, your client application would also need to be updated to handle this (e.g., by using our library to send out new RTSP "SETUP" and "PLAY" commands, reopen (& resize) the video display window, etc.). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at m2mservices.mobi Thu Nov 7 07:50:13 2013 From: info at m2mservices.mobi (info at m2mservices.mobi) Date: Thu, 7 Nov 2013 15:50:13 +0000 Subject: [Live-devel] Handling a change of codec midstream In-Reply-To: <9F45A2E8-E617-4064-AEDE-01EC15E1D106@live555.com> References: , <9F45A2E8-E617-4064-AEDE-01EC15E1D106@live555.com> Message-ID: I assume it was the only mechanism they had available to support the change of payload. The Client is the Video Edge Go iOS app which we developed. Its good to know that you would consider custom development - Ill be able to discuss that with them. if we go down that route I will be able to incorporate a custom version of the library. Thanks for the Live555 product it is an excellent library and thanks for the feedback. Regards Aidan From: finlayson at live555.com Date: Thu, 7 Nov 2013 06:54:05 -0800 To: live-devel at ns.live555.com Subject: Re: [Live-devel] Handling a change of codec midstream The server uses an ANNOUNCE command to notify the client that this transcode about to take place. Wow - this is a very obscure feature of the RTSP protocol: sending an "ANNOUNCE" command from the server to the client. This is the first time that I have ever heard of a server that does this. (Note, BTW, that the "ANNOUNCE" command - because it was poorly specified and rarely used - has been removed entirely from the proposed "RTSP 2.0" update to RTSP.) The change in Payload would cause an error normally - do you think it is possible for Live555 to be adjusted to handle this payload change mid stream? Yes, conceivably. However, adding support for a feature like this is not something that we would do for free. If anyone (e.g., American Dynamics, which manufacturers the "VideoEdge NVR") is interested in paying for this, please let me know (by separate email). Also, you didn't say anything about which client application (using the "LIVE555 Streaming Media" code) you are using. Note that even if our library were updated to support this obscure server->client "ANNOUNCE" command, your client application would also need to be updated to handle this (e.g., by using our library to send out new RTSP "SETUP" and "PLAY" commands, reopen (& resize) the video display window, etc.). 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 Thu Nov 7 08:21:03 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 7 Nov 2013 08:21:03 -0800 Subject: [Live-devel] Handling a change of codec midstream In-Reply-To: References: , <9F45A2E8-E617-4064-AEDE-01EC15E1D106@live555.com> Message-ID: <291D1728-B32B-465C-84F9-5AB73D91B207@live555.com> > The Client is the Video Edge Go iOS app which we developed. > Its good to know that you would consider custom development - Ill be able to discuss that with them. if we go down that route I will be able to incorporate a custom version of the library. Yes. Note, however, that any 'custom version' of the library would be subject to the conditions of the LGPL. American Dynamics - when it distributes the "Video Edge Go Mobile App" - would need to also distribute whatever patches were made to produce the 'custom version' of the library. That's why it would be better to have support for 'server->client ANNOUNCE' be made part of the official "LIVE555 Streaming Media" release. (However, as I noted earlier, that's not something that we will be doing 'for free'.) (A reminder also, BTW, that the "Video Edge Go Mobile App" - even if it uses an unmodified version of the "LIVE555 Streaming Media" software - is subject to the conditions of the LGPL, which implies that American Dynamics must be prepared to, whenever requested, upgrade it to use the latest version of the library. See .) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at m2mservices.mobi Thu Nov 7 08:39:13 2013 From: info at m2mservices.mobi (info at m2mservices.mobi) Date: Thu, 7 Nov 2013 16:39:13 +0000 Subject: [Live-devel] Handling a change of codec midstream In-Reply-To: <291D1728-B32B-465C-84F9-5AB73D91B207@live555.com> References: , , <9F45A2E8-E617-4064-AEDE-01EC15E1D106@live555.com>, , <291D1728-B32B-465C-84F9-5AB73D91B207@live555.com> Message-ID: We develop and maintain the app so if you want to request an update please send me an email. From: finlayson at live555.com Date: Thu, 7 Nov 2013 08:21:03 -0800 To: live-devel at ns.live555.com Subject: Re: [Live-devel] Handling a change of codec midstream The Client is the Video Edge Go iOS app which we developed. Its good to know that you would consider custom development - Ill be able to discuss that with them. if we go down that route I will be able to incorporate a custom version of the library. Yes. Note, however, that any 'custom version' of the library would be subject to the conditions of the LGPL. American Dynamics - when it distributes the "Video Edge Go Mobile App" - would need to also distribute whatever patches were made to produce the 'custom version' of the library. That's why it would be better to have support for 'server->client ANNOUNCE' be made part of the official "LIVE555 Streaming Media" release. (However, as I noted earlier, that's not something that we will be doing 'for free'.) (A reminder also, BTW, that the "Video Edge Go Mobile App" - even if it uses an unmodified version of the "LIVE555 Streaming Media" software - is subject to the conditions of the LGPL, which implies that American Dynamics must be prepared to, whenever requested, upgrade it to use the latest version of the library. See .) 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 michel.promonet at thalesgroup.com Fri Nov 8 07:20:50 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Fri, 8 Nov 2013 16:20:50 +0100 Subject: [Live-devel] Matroska BANK_SIZE overflow In-Reply-To: <2817_1383748623_527A540F_2817_7522_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB95A45@THSONEA01CMS01P.one.grp> References: <31396_1383153571_52713FA3_31396_3808_1_1BE8971B6CFF3A4F97AF4011882AA25501563E9ED5C5@THSONEA01CMS01P.one.grp> <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> <837A6C91-8E03-42C2-8CDB-503757429C73@live555.com> <8476DB13-01FA-4DD4-9C22-B722F391A756@live555.com> <15978_1383658567_5278F447_15978_894_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB21FF4@THSONEA01CMS01P.one.grp> <2817_1383748623_527A540F_2817_7522_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB95A45@THSONEA01CMS01P.one.grp> Message-ID: <1599_1383924052_527D0153_1599_2004_1_1BE8971B6CFF3A4F97AF4011882AA25501563EC57202@THSONEA01CMS01P.one.grp> Hi Ross, I continue to test mkv and I found another file that makes also abort testOnDemandRTSPServer. You can download the test file http://dl.free.fr/uoSMgnOAg Don't you think it could be kind to return instead of aborting, but perhaps it is not easy to throw up the overflow... 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 PROMONET Michel Envoy? : mercredi 6 novembre 2013 15:37 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Matroska BANK_SIZE overflow Hi Ross, This is clearer like this. Thank a lot. 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? : mercredi 6 novembre 2013 05:45 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Matroska BANK_SIZE overflow Surely I badly use the matroska parser... What I was trying to do is to connect each matroska subsession to a sink. In fact I don't need ServerMediaSession, it is just to get the FramedSource corresponding to a subsession. The "MatroskaFileServerDemux" class should be used only within a RTSP server, in which case you don't 'play' the demultiplexed tracks directly; instead, this is done indirectly, via the RTSP server implementation. I'm not sure exactly why the BANK_SIZE error was occurring for your application, but it turns out that you weren't using the API in the intended way. If you want to demultiplex the tracks from a Matroska file directly - without a RTSP server - then you can do this; however, the API didn't make this clear. That was my fault. To fix this, I have installed a new version (2013.11.06) of the "LIVE555 Streaming Media" code that improves and clarifies the API for demultiplexing a Matroska file. The following is a version of your demo application that uses the new, cleaned-up API to demultiplex a Matroska file into files for its constituent tracks. (When I run this, I don't get the BANK_SIZE error.) /////////////////////////// #include "liveMedia.hh" #include "BasicUsageEnvironment.hh" static char newMatroskaFileWatchVariable = 0; static MatroskaFile* matroskaFile; static void onMatroskaFileCreation(MatroskaFile* newFile, void* /*clientData*/) { matroskaFile = newFile; newMatroskaFileWatchVariable = 1; } int main(int argc, char** argv) { TaskScheduler* scheduler = BasicTaskScheduler::createNew(); UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler); // Open a Matroska file: char const* inputFileName = "test.mkv"; MatroskaFile::createNew(*env, inputFileName, onMatroskaFileCreation, NULL); env->taskScheduler().doEventLoop(&newMatroskaFileWatchVariable); // Create a demultiplexor from the file: MatroskaDemux* demux = matroskaFile->newDemux(); // And start copying each track: unsigned const fileSinkBufferSize = 300000; while (1) { unsigned trackNumber; FramedSource* trackSource = demux->newDemuxedTrack(trackNumber); if (trackSource == NULL) break; // For reference, display information about each track: MatroskaTrack* trackInfo = matroskaFile->lookup(trackNumber); fprintf(stderr, "Reading track %d, codec: %s\n", trackNumber, trackInfo->codecID); char outFileName[100]; sprintf(outFileName, "track%d", trackNumber); MediaSink* sink = FileSink::createNew(*env, outFileName, fileSinkBufferSize, False); sink->startPlaying(*trackSource,NULL,NULL); } env->taskScheduler().doEventLoop(); return 0; } Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nambirajan.manickam at i-velozity.com Fri Nov 8 21:45:36 2013 From: nambirajan.manickam at i-velozity.com (Nambirajan M) Date: Sat, 9 Nov 2013 11:15:36 +0530 Subject: [Live-devel] Current play time during FFW / REW in Get_Parameter function Message-ID: <001701cedd0e$ecee3d80$c6cab880$@manickam@i-velozity.com> Hi Ross, How to get the current play time during FFW and REW in Get_Parameter(); We were able to get the current play time during normal playback in Get_Parameter() by implementation; Thanks and regards, M. Nambirajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 8 22:43:30 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 8 Nov 2013 22:43:30 -0800 Subject: [Live-devel] Current play time during FFW / REW in Get_Parameter function In-Reply-To: <001701cedd0e$ecee3d80$c6cab880$@manickam@i-velozity.com> References: <001701cedd0e$ecee3d80$c6cab880$@manickam@i-velozity.com> Message-ID: > How to get the current play time during FFW and REW in Get_Parameter(); I don't know what "Get_Parameter()" is supposed to be; we don't have a function with that name. The function for RTSP clients to call to get the stream's 'normal play time' is MediaSubsession::getNormalPlayTime() (see "liveMedia/include/MediaSession.hh") Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Nov 9 21:31:47 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 9 Nov 2013 21:31:47 -0800 Subject: [Live-devel] Matroska BANK_SIZE overflow In-Reply-To: <1599_1383924052_527D0153_1599_2004_1_1BE8971B6CFF3A4F97AF4011882AA25501563EC57202@THSONEA01CMS01P.one.grp> References: <31396_1383153571_52713FA3_31396_3808_1_1BE8971B6CFF3A4F97AF4011882AA25501563E9ED5C5@THSONEA01CMS01P.one.grp> <27363_1383558989_52776F4D_27363_1963_1_1BE8971B6CFF3A4F97AF4011882AA25501563EA7FDB0@THSONEA01CMS01P.one.grp> <837A6C91-8E03-42C2-8CDB-503757429C73@live555.com> <8476DB13-01FA-4DD4-9C22-B722F391A756@live555.com> <15978_1383658567_5278F447_15978_894_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB21FF4@THSONEA01CMS01P.one.grp> <2817_1383748623_527A540F_2817_7522_1_1BE8971B6CFF3A4F97AF4011882AA25501563EB95A45@THSONEA01CMS01P.one.grp> <1599_1383924052_527D0153_1599_2004_1_1BE8971B6CFF3A4F97AF4011882AA25501563EC57202@THSONEA01CMS01P.one.grp> Message-ID: <748D597F-1948-4E6A-8DF2-879662BF9C8E@live555.com> > I continue to test mkv and I found another file that makes also abort testOnDemandRTSPServer. OK, thanks for the report. The problem here is that our parser wasn't properly skipping over the very large 'file attachments' embedded within the Matroska file. I've now installed a new version (2013.11.10) of the "LIVE555 Streaming Media" code that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nambirajan.manickam at i-velozity.com Sun Nov 10 19:43:00 2013 From: nambirajan.manickam at i-velozity.com (Nambirajan M) Date: Mon, 11 Nov 2013 09:13:00 +0530 Subject: [Live-devel] Current play time during FFW / REW in Get_Parameter function In-Reply-To: References: <001701cedd0e$ecee3d80$c6cab880$@manickam@i-velozity.com> Message-ID: <000801cede90$22906b70$67b14250$@manickam@i-velozity.com> Hi Ross, Sorry for the type error, we used MediaSubsession::getNormalPlayTime() in the handleCmd_GET_PARAMETER() and got the current play time. But when we do the FFW and REW we are getting the same time ( that is X1), not the play time at different speed like X2, X4 etc. Do we need to do something to implement the same. Please 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: Saturday, November 09, 2013 12:14 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Current play time during FFW / REW in Get_Parameter function How to get the current play time during FFW and REW in Get_Parameter(); I don't know what "Get_Parameter()" is supposed to be; we don't have a function with that name. The function for RTSP clients to call to get the stream's 'normal play time' is MediaSubsession::getNormalPlayTime() (see "liveMedia/include/MediaSession.hh") Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Nov 10 20:12:10 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 10 Nov 2013 20:12:10 -0800 Subject: [Live-devel] Current play time during FFW / REW in Get_Parameter function In-Reply-To: <000801cede90$22906b70$67b14250$@manickam@i-velozity.com> References: <001701cedd0e$ecee3d80$c6cab880$@manickam@i-velozity.com> <000801cede90$22906b70$67b14250$@manickam@i-velozity.com> Message-ID: <45B023E7-436E-450C-A04A-C95E5AF59B6C@live555.com> we used MediaSubsession::getNormalPlayTime() in the handleCmd_GET_PARAMETER() and got the current play time. > But when we do the FFW and REW we are getting the same time ( that is X1), not the play time at different speed like X2, X4 etc. The "getNormalPlayTime()" function is supposed to take the scaling factor into account. So I don't know why it's not working for you. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From enchaogu at gmail.com Mon Nov 11 16:15:50 2013 From: enchaogu at gmail.com (enchao gu) Date: Tue, 12 Nov 2013 08:15:50 +0800 Subject: [Live-devel] a bug about live555? In-Reply-To: References: Message-ID: when live555 works in server mode, two pachets comes at once by rtsp over tcp while starting, if the firtst packet is rtsp protocal , the second is rtcp data , in function "void RTSPServer::RTSPClientConnection::incomingRequestHandler1() " will receive all data, function "handleRequestBytes" can parse correct cmd, but rtcp data will stay in "fRequestBuffer", then if another rtsp protocal comes, now it can't parse correct, can i drop the rtcp data? -------------- next part -------------- A non-text attachment was scrubbed... Name: print.JPG Type: image/jpeg Size: 79340 bytes Desc: not available URL: From finlayson at live555.com Mon Nov 11 16:52:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Nov 2013 16:52:06 -0800 Subject: [Live-devel] a bug about live555? In-Reply-To: References: Message-ID: The bug here is in the RTSP *client* - i.e., VLC. It is running an old, buggy version of the "LIVE555 Streaming Media" library. I have asked the VLC developers to update to using a more recent version of our library in their binary distribution. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From umar at janteq.com Tue Nov 12 15:22:59 2013 From: umar at janteq.com (Umar Qureshey) Date: Tue, 12 Nov 2013 23:22:59 +0000 Subject: [Live-devel] live555 TS muxer broken? Message-ID: Hi, I have been told second-hand that the TS muxer in Live555 is broken. Without knowing the details, I was wondering whether this is true or not? I don't want to spin my wheels on a broken implementation. I am trying to use Live555 to connect to a streaming IP camera using RTSP. The camera is sending H.264-ES over RTP, I'd like to depayload the H.264-ES stream, and then mux it to create MPEG-TS which I'd like to save to a file. I have found this reference which is pretty much all I want to do: http://lists.live555.com/pipermail/live-devel/2013-April/016899.html Thanks. From warren at etr-usa.com Tue Nov 12 16:13:20 2013 From: warren at etr-usa.com (Warren Young) Date: Tue, 12 Nov 2013 17:13:20 -0700 Subject: [Live-devel] live555 TS muxer broken? In-Reply-To: References: Message-ID: <5282C420.3090806@etr-usa.com> On 11/12/2013 16:22, Umar Qureshey wrote: > > I have been told second-hand that the TS muxer in Live555 is broken. Told by whom, and what exactly do they mean by "broken"? TS covers a whole lot of ground, and I have yet to use a TS muxer that can produce every legal type of TS file. "Broken" may be shorthand for, "It can't produce the exact TS flavor we want, and we're not willing to expand the set of TS flavors we will tolerate." How hard would it be to just try it? Create the TS file with Live555, then see if your target player will consume it. If not, make them tell you what exactly is "broken" about it. "It's broken" is not a useful bug report. From umar at janteq.com Tue Nov 12 16:23:10 2013 From: umar at janteq.com (Umar Qureshey) Date: Wed, 13 Nov 2013 00:23:10 +0000 Subject: [Live-devel] live555 TS muxer broken? In-Reply-To: <5282C420.3090806@etr-usa.com> References: <5282C420.3090806@etr-usa.com> Message-ID: > -----Original Message----- > From: live-devel-bounces at ns.live555.com [mailto:live-devel- > bounces at ns.live555.com] On Behalf Of Warren Young > Sent: Tuesday, November 12, 2013 4:13 PM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] live555 TS muxer broken? > > On 11/12/2013 16:22, Umar Qureshey wrote: > > > > I have been told second-hand that the TS muxer in Live555 is broken. > > Told by whom, and what exactly do they mean by "broken"? > > TS covers a whole lot of ground, and I have yet to use a TS muxer that can > produce every legal type of TS file. "Broken" may be shorthand for, "It can't > produce the exact TS flavor we want, and we're not willing to expand the set > of TS flavors we will tolerate." > > How hard would it be to just try it? Create the TS file with Live555, then see if > your target player will consume it. If not, make them tell you what exactly is > "broken" about it. "It's broken" is not a useful bug report. You are correct. I will try to use the TS Muxer and report if it doesn't work. I just thought if it was a known issue then I can be aware of it before the get-go. I have just used testH264VideoToTransportStream to convert an ES file saved using openRTSP and converted it to TS. It all seems fine; VLC plays it fine and my TS analyzer doesn't report any showstoppers. From raghav at fossilshale.com Wed Nov 13 02:05:43 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Wed, 13 Nov 2013 15:35:43 +0530 Subject: [Live-devel] Playsip not working Message-ID: <20131113153543.22903odayk646v3r@just60.justhost.com> Hi Ross, Am trying to use playsip whenever am running it am getting error Loop detected error. ./playSip sip:username at iptel.org what will be the issue? Thanks, Raghav. From vlahovic74 at gmail.com Wed Nov 13 05:19:18 2013 From: vlahovic74 at gmail.com (Marko Vlahovic) Date: Wed, 13 Nov 2013 08:19:18 -0500 Subject: [Live-devel] (no subject) Message-ID: Hi I would like to propose two additional features for openRTSP: 1. Adding user agent string option For example: openRTSP -Q -D 2 -C "BlackBerry9100" rtsp:// 127.0.0.1:554/ClickTrailer_320x240_30FPS_h264_aac.mp4 2. Adding a bind option For example: openRTSP -Q -D 2 -C "BlackBerry9100" -N 192.168.0.100 rtsp:// 127.0.0.1:554/ClickTrailer_320x240_30FPS_h264_aac.mp4 If interested, please find attached patch files that describe necessary changes for these two features to work. Let me know if you are interested. Best Regards, Marko -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-user-agent.patch Type: application/octet-stream Size: 3346 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 00-bind-IP.patch Type: application/octet-stream Size: 2905 bytes Desc: not available URL: From finlayson at live555.com Wed Nov 13 07:29:53 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 13 Nov 2013 07:29:53 -0800 Subject: [Live-devel] Playsip not working In-Reply-To: <20131113153543.22903odayk646v3r@just60.justhost.com> References: <20131113153543.22903odayk646v3r@just60.justhost.com> Message-ID: > Am trying to use playsip whenever am running it am getting error Loop detected error. > ./playSip sip:username at iptel.org > > what will be the issue? What a useless question! Why don't you post the protocol exchange, and the actual error message?! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at honeywell.com Wed Nov 13 10:00:50 2013 From: Giridhara.Kalkere at honeywell.com (Kalkere, Giridhara(IE10)) Date: Wed, 13 Nov 2013 18:00:50 +0000 Subject: [Live-devel] MPEG-TS in LIVE media. Message-ID: <955512E27CA4E9478883ACDCA9CA40C699FC91@IE1AEX3007.global.ds.honeywell.com> Hello Ross, How are you doing? Hope everything good in your end. We are using the LIVE555 framework to stream a camera and store the video streams in raw format. Whenever required we convert it into the .mp4 and play it on the clients (IOS/android devices). Now I was thinking of storing the camera video (MPEG/H264) in small chunks of .ts files. So that my clip management will be very easy and also streaming to the clients doesn't need to convert it into .mp4. It will be very great if you advice me in this design idea. What are the things I need to use to accomplish this. Thank and Regards, Giri -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Wed Nov 13 14:48:19 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Wed, 13 Nov 2013 15:48:19 -0700 Subject: [Live-devel] rtsp proxy stops streaming Message-ID: <528401B3.8060504@vivint.com> I'm wondering if there is a specific message I can look for in the logs when at level 2 that will indicate if a proxies stream has failed? I'm using the proxyServer example and at times the stream stops streaming. I can see the OPTION commands going out to the camera with a response, but connecting a client to the proxied stream does not work. Not sure if it is due to loosing a connection, but what I find strange is the OPTION command appears to respond. Is there something in the response of the OPTION that indicates a problem? Thanks, Craig From finlayson at live555.com Wed Nov 13 15:06:13 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 13 Nov 2013 15:06:13 -0800 Subject: [Live-devel] rtsp proxy stops streaming In-Reply-To: <528401B3.8060504@vivint.com> References: <528401B3.8060504@vivint.com> Message-ID: <1CB4FEF9-EE1B-4CCC-9DC1-85BBC6BA8F93@live555.com> > I'm wondering if there is a specific message I can look for in the logs > when at level 2 that will indicate if a proxies stream has failed? I'm > using the proxyServer example and at times the stream stops streaming. > I can see the OPTION commands going out to the camera with a response, > but connecting a client to the proxied stream does not work. Not sure > if it is due to loosing a connection, but what I find strange is the > OPTION command appears to respond. Is there something in the response > of the OPTION that indicates a problem? I'm not sure. Why don't you post the diagnostic output (from the proxy server) around the time that "connecting a client to the proxied stream does not work"? (And also, please clarify what "does not work" means). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From umar at janteq.com Wed Nov 13 15:16:15 2013 From: umar at janteq.com (Umar Qureshey) Date: Wed, 13 Nov 2013 23:16:15 +0000 Subject: [Live-devel] RTSP (RTP) -> H.264ES -> MPEG2-TS muxing problem Message-ID: Hi, I am attempting to grab an H.264 ES stream from a streaming IP camera and mux it to a TS and save to a file. I have modified the testRTSPClient.cpp demo program to accomplish this. Basically, I modified it such that I get the H.264-ES, then I pass it through the H264VideoStreamDiscreteFramer filter, then I pass it through MPEG2TransportStreamFromESSource filter, and then I pass it to FileSink. The program runs fine and creates a TS file but I am unable to play it on VLC and my TS analyzer reports bad video data. Here are the relevant changes I have made to testRTSPClient.cpp (modifications are prefaced by UQ); most of the action is in continueAfterSETUP() and I have posted only the functions I have modified but a full patch is also pasted at the end: class ourRTSPClient: public RTSPClient { public: static ourRTSPClient* createNew(UsageEnvironment& env, char const* rtspURL, int verbosityLevel = 0, char const* applicationName = NULL, portNumBits tunnelOverHTTPPortNum = 0); protected: ourRTSPClient(UsageEnvironment& env, char const* rtspURL, int verbosityLevel, char const* applicationName, portNumBits tunnelOverHTTPPortNum); // called only by createNew(); virtual ~ourRTSPClient(); public: StreamClientState scs; //UQ 11/13/2013 Declare H.264-ES to MPEG2-TS converter. MPEG2TransportStreamFromESSource *outputTSStream; //UQ 11/13/2013 Declare H.264-ES Framer. H264VideoStreamDiscreteFramer* H264framer; }; void continueAfterSETUP(RTSPClient* rtspClient, int resultCode, char* resultString) { do { UsageEnvironment& env = rtspClient->envir(); // alias StreamClientState& scs = ((ourRTSPClient*)rtspClient)->scs; // alias if (resultCode != 0) { env << *rtspClient << "Failed to set up the \"" << *scs.subsession << "\" subsession: " << resultString << "\n"; break; } env << *rtspClient << "Set up the \"" << *scs.subsession << "\" subsession (client ports " << scs.subsession->clientPortNum() << "-" << scs.subsession->clientPortNum()+1 << ")\n"; // Having successfully setup the subsession, create a data sink for it, and call "startPlaying()" on it. // (This will prepare the data sink to receive data; the actual flow of data from the client won't start happening until later, // after we've sent a RTSP "PLAY" command.) //UQ 11/12/2013 Replace with FileSink. #if 0 scs.subsession->sink = DummySink::createNew(env, *scs.subsession, rtspClient->url()); #endif scs.subsession->sink = FileSink::createNew(env, "/tmp/live555.ts", 2000000); // perhaps use your own custom "MediaSink" subclass instead if (scs.subsession->sink == NULL) { env << *rtspClient << "Failed to create a data sink for the \"" << *scs.subsession << "\" subsession: " << env.getResultMsg() << "\n"; break; } env << *rtspClient << "Created a data sink for the \"" << *scs.subsession << "\" subsession\n"; scs.subsession->miscPtr = rtspClient; // a hack to let subsession handle functions get the "RTSPClient" from the subsession env << "Video source is " << scs.subsession->mediumName() << "\n"; ((ourRTSPClient*)rtspClient)->H264framer = H264VideoStreamDiscreteFramer::createNew(env, scs.subsession->readSource()); //UQ 11/13/2013 Add H.264 Video source to MPEG2-TS converter. ((ourRTSPClient*)rtspClient)->outputTSStream->addNewVideoSource(((ourRTSPClient*)rtspClient)->H264framer, 5); //UQ 11/13/2013 We don't want to save ES data so comment this out. #if 0 scs.subsession->sink->startPlaying(*(scs.subsession->readSource()), subsessionAfterPlaying, scs.subsession); #endif //UQ 11/13/2013 Save the muxed TS file. scs.subsession->sink->startPlaying(*((ourRTSPClient*)rtspClient)->outputTSStream, subsessionAfterPlaying, scs.subsession); // Also set a handler to be called if a RTCP "BYE" arrives for this subsession: if (scs.subsession->rtcpInstance() != NULL) { scs.subsession->rtcpInstance()->setByeHandler(subsessionByeHandler, scs.subsession); } } while (0); delete[] resultString; // Set up the next subsession, if any: setupNextSubsession(rtspClient); } void subsessionAfterPlaying(void* clientData) { MediaSubsession* subsession = (MediaSubsession*)clientData; RTSPClient* rtspClient = (RTSPClient*)(subsession->miscPtr); // Begin by closing this subsession's stream: Medium::close(subsession->sink); subsession->sink = NULL; //UQ 11/13/2013 Release H264framer resources. Medium::close(((ourRTSPClient*)rtspClient)->H264framer); // Next, check whether *all* subsessions' streams have now been closed: MediaSession& session = subsession->parentSession(); MediaSubsessionIterator iter(session); while ((subsession = iter.next()) != NULL) { if (subsession->sink != NULL) return; // this subsession is still active } // All subsessions' streams have now been closed, so shutdown the client: shutdownStream(rtspClient); } void shutdownStream(RTSPClient* rtspClient, int exitCode) { UsageEnvironment& env = rtspClient->envir(); // alias StreamClientState& scs = ((ourRTSPClient*)rtspClient)->scs; // alias // First, check whether any subsessions have still to be closed: if (scs.session != NULL) { Boolean someSubsessionsWereActive = False; MediaSubsessionIterator iter(*scs.session); MediaSubsession* subsession; while ((subsession = iter.next()) != NULL) { if (subsession->sink != NULL) { Medium::close(subsession->sink); subsession->sink = NULL; //UQ 11/13/2013 Release H264framer resources. Medium::close(((ourRTSPClient*)rtspClient)->H264framer); if (subsession->rtcpInstance() != NULL) { subsession->rtcpInstance()->setByeHandler(NULL, NULL); // in case the server sends a RTCP "BYE" while handling "TEARDOWN" } someSubsessionsWereActive = True; } } if (someSubsessionsWereActive) { // Send a RTSP "TEARDOWN" command, to tell the server to shutdown the stream. // Don't bother handling the response to the "TEARDOWN". rtspClient->sendTeardownCommand(*scs.session, NULL); } } env << *rtspClient << "Closing the stream.\n"; Medium::close(rtspClient); // Note that this will also cause this stream's "StreamClientState" structure to get reclaimed. if (--rtspClientCount == 0) { // The final stream has ended, so exit the application now. // (Of course, if you're embedding this code into your own application, you might want to comment this out, // and replace it with "eventLoopWatchVariable = 1;", so that we leave the LIVE555 event loop, and continue running "main()".) exit(exitCode); } } ourRTSPClient::ourRTSPClient(UsageEnvironment& env, char const* rtspURL, int verbosityLevel, char const* applicationName, portNumBits tunnelOverHTTPPortNum) : RTSPClient(env,rtspURL, verbosityLevel, applicationName, tunnelOverHTTPPortNum, -1) { //UQ 11/13/2013 Instantiate MPEG2 TS muxer. outputTSStream = MPEG2TransportStreamFromESSource::createNew(env); } ourRTSPClient::~ourRTSPClient() { //UQ 11/13/2013 Free MPEG2 TS muxer instance. Medium::close(outputTSStream); } ----- FULL PATCH ----- --- testRTSPClient.cpp.orig 2013-11-12 15:31:25.318574152 -0800 +++ testRTSPClient.cpp 2013-11-13 14:22:48.505537734 -0800 @@ -128,8 +128,15 @@ public: StreamClientState scs; + //UQ 11/13/2013 Declare H.264-ES to MPEG2-TS converter. + MPEG2TransportStreamFromESSource *outputTSStream; + //UQ 11/13/2013 Declare H.264-ES Framer. + H264VideoStreamDiscreteFramer* H264framer; }; + +//UQ 11/12/2013 Remove DummySink and replace with FileSink. +#if 0 // Define a data sink (a subclass of "MediaSink") to receive the data for each subsession (i.e., each audio or video 'substream'). // In practice, this might be a class (or a chain of classes) that decodes and then renders the incoming audio or video. // Or it might be a "FileSink", for outputting the received data into a file (as is done by the "openRTSP" application). @@ -162,6 +169,8 @@ MediaSubsession& fSubsession; char* fStreamId; }; +#endif + #define RTSP_CLIENT_VERBOSITY_LEVEL 1 // by default, print verbose output from each "RTSPClient" @@ -274,7 +283,12 @@ // (This will prepare the data sink to receive data; the actual flow of data from the client won't start happening until later, // after we've sent a RTSP "PLAY" command.) +//UQ 11/12/2013 Replace with FileSink. +#if 0 scs.subsession->sink = DummySink::createNew(env, *scs.subsession, rtspClient->url()); +#endif + scs.subsession->sink = FileSink::createNew(env, "/tmp/live555.ts", 2000000); + // perhaps use your own custom "MediaSink" subclass instead if (scs.subsession->sink == NULL) { env << *rtspClient << "Failed to create a data sink for the \"" << *scs.subsession @@ -284,8 +298,21 @@ env << *rtspClient << "Created a data sink for the \"" << *scs.subsession << "\" subsession\n"; scs.subsession->miscPtr = rtspClient; // a hack to let subsession handle functions get the "RTSPClient" from the subsession + env << "Video source is " << scs.subsession->mediumName() << "\n"; + + ((ourRTSPClient*)rtspClient)->H264framer = H264VideoStreamDiscreteFramer::createNew(env, scs.subsession->readSource()); + + //UQ 11/13/2013 Add H.264 Video source to MPEG2-TS converter. + ((ourRTSPClient*)rtspClient)->outputTSStream->addNewVideoSource(((ourRTSPClient*)rtspClient)->H264framer, 5); + +//UQ 11/13/2013 We don't want to save ES data so comment this out. +#if 0 scs.subsession->sink->startPlaying(*(scs.subsession->readSource()), subsessionAfterPlaying, scs.subsession); +#endif + //UQ 11/13/2013 Save the muxed TS file. + scs.subsession->sink->startPlaying(*((ourRTSPClient*)rtspClient)->outputTSStream, + subsessionAfterPlaying, scs.subsession); // Also set a handler to be called if a RTCP "BYE" arrives for this subsession: if (scs.subsession->rtcpInstance() != NULL) { scs.subsession->rtcpInstance()->setByeHandler(subsessionByeHandler, scs.subsession); @@ -347,6 +374,9 @@ Medium::close(subsession->sink); subsession->sink = NULL; + //UQ 11/13/2013 Release H264framer resources. + Medium::close(((ourRTSPClient*)rtspClient)->H264framer); + // Next, check whether *all* subsessions' streams have now been closed: MediaSession& session = subsession->parentSession(); MediaSubsessionIterator iter(session); @@ -393,6 +423,8 @@ if (subsession->sink != NULL) { Medium::close(subsession->sink); subsession->sink = NULL; + //UQ 11/13/2013 Release H264framer resources. + Medium::close(((ourRTSPClient*)rtspClient)->H264framer); if (subsession->rtcpInstance() != NULL) { subsession->rtcpInstance()->setByeHandler(NULL, NULL); // in case the server sends a RTCP "BYE" while handling "TEARDOWN" @@ -432,9 +464,13 @@ ourRTSPClient::ourRTSPClient(UsageEnvironment& env, char const* rtspURL, int verbosityLevel, char const* applicationName, portNumBits tunnelOverHTTPPortNum) : RTSPClient(env,rtspURL, verbosityLevel, applicationName, tunnelOverHTTPPortNum, -1) { + //UQ 11/13/2013 Instantiate MPEG2 TS muxer. + outputTSStream = MPEG2TransportStreamFromESSource::createNew(env); } ourRTSPClient::~ourRTSPClient() { + //UQ 11/13/2013 Free MPEG2 TS muxer instance. + Medium::close(outputTSStream); } @@ -456,6 +492,8 @@ } +//UQ 11/12/2013 Remove DummySink and replace with FileSink. +#if 0 // Implementation of "DummySink": // Even though we're not going to be doing anything with the incoming data, we still need to receive it. @@ -519,3 +557,5 @@ onSourceClosure, this); return True; } +#endif + From finlayson at live555.com Wed Nov 13 16:08:23 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 13 Nov 2013 16:08:23 -0800 Subject: [Live-devel] live555 TS muxer broken? In-Reply-To: References: <5282C420.3090806@etr-usa.com> Message-ID: > I have just used testH264VideoToTransportStream to convert an ES file saved using openRTSP and converted it to TS. Note that you can easily do this without using an intermediate ES file. (Instead, you use a pipe.): In "testH264VideoToTransportStream.cpp", change "inputFileName" from "in.264" to "stdin". Then run openRTSP -v rtsp://your-rtsp-stream-url | your-modified-testH264VideoToTransportStream-application and you'll get your Transport Stream file (in "out.ts"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 13 21:35:54 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 13 Nov 2013 21:35:54 -0800 Subject: [Live-devel] (your proposed new options for "openRTSP") In-Reply-To: References: Message-ID: <602F7F39-9EC7-4D01-AA90-A3D3943523CE@live555.com> > I would like to propose two additional features for openRTSP: > 1. Adding user agent string option > For example: openRTSP -Q -D 2 -C "BlackBerry9100" rtsp://127.0.0.1:554/ClickTrailer_320x240_30FPS_h264_aac.mp4 > 2. Adding a bind option Thanks for the note. I've just installed a new version (2013.11.14) of the "LIVE555 Streaming Media" software that adds a new option -g to both "openRTSP" and "playSIP". (Note: "-C" option was already for a (previously) undocumented option.) I didn't add your proposed second option, because there's already an option "-I " that does this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john95018 at gmail.com Wed Nov 13 08:57:25 2013 From: john95018 at gmail.com (john dicostanzo) Date: Wed, 13 Nov 2013 22:27:25 +0530 Subject: [Live-devel] Multiple session in Live555 Message-ID: HI Ross, I am new to Live555. I am using your test app "testOndemandRtspServer",i want to know that how its maintain multiple clients session internally. is it create multiple process?? Thanks and Regards, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 13 21:50:29 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 13 Nov 2013 21:50:29 -0800 Subject: [Live-devel] MPEG-TS in LIVE media. In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C699FC91@IE1AEX3007.global.ds.honeywell.com> References: <955512E27CA4E9478883ACDCA9CA40C699FC91@IE1AEX3007.global.ds.honeywell.com> Message-ID: <5CB52840-CB2A-4556-A3ED-41CA08DE32F1@live555.com> > We are using the LIVE555 framework to stream a camera and store the video streams in raw format. Whenever required we convert it into the .mp4 and play it on the clients (IOS/android devices). > Now I was thinking of storing the camera video (MPEG/H264) in small chunks of .ts files. Note our "openRTSP" demo application - which saves a H.264 RTSP/RTP stream into a H.264 Video Elementary Stream file. Note also our "testH264VideoToTransportStream" demo application, which converts a H.264 Video Elementary Stream file into a Transport Stream file. Note also that you can combine these two applications, using a pipe. See http://lists.live555.com/pipermail/live-devel/2013-November/017695.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Nov 14 01:40:02 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 14 Nov 2013 10:40:02 +0100 Subject: [Live-devel] Allow access to RTPSink when ServerMediaSubsession is overired Message-ID: <10632_1384422008_52849A78_10632_9993_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDA31B5@THSONEA01CMS01P.one.grp> Hi Ross, The RTSP server we develop based on live555 implementation override the ServerMediaSubsession class. But in order to get some informations that are owned by the RTPSink we store (in our overriding class) the RTPSink returned by the createNewRTPSink. This is not nice but not a big problem, just store twice the same thing. But it becomes tricky because the createNewRTPSink is also used during RTSP describe. Then, do you think it could be possible to reduce the privacy of ServerMediaSubsession::fRTPSink and define it as protected ? Thanks and Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ognjenm at rcub.bg.ac.rs Thu Nov 14 08:53:44 2013 From: ognjenm at rcub.bg.ac.rs (=?iso-8859-2?Q?Ognjen_Milosavljevi=E6?=) Date: Thu, 14 Nov 2013 17:53:44 +0100 Subject: [Live-devel] VLC and The LIVE555 Proxy Server Message-ID: <001b01cee15a$149c58e0$3dd50aa0$@rcub.bg.ac.rs> Hi, i want to stream unicast from VLC and restream it over unicast to various addresses using LIVE555 Proxy Server. When I try to restream, rtsp stream from VLC, I get these messages on LIVE555 Proxy Server: ProxyRTSPClient["rtsp://XXX"]: RTSP "DESCRIBE" command failed; trying again in 1 seconds Opening connection to YYY, port ZZZ... ...Connection to server failed: Connection timed out ProxyRTSPClient["rtsp://XXX"]: RTSP "DESCRIBE" command failed; trying again in 2 seconds Opening connection to YYY, port ZZZ... ...Connection to server failed: Connection timed out ProxyRTSPClient["rtsp://XXX "]: RTSP "DESCRIBE" command failed; trying again in 4 seconds Opening connection to YYY, port ZZZ... ...Connection to server failed: Connection timed out ProxyRTSPClient["rtsp:// XXX "]: RTSP "DESCRIBE" command failed; trying again in 8 seconds Also I confirmed streaming from VLC with VLC on the other pc and it was working fine, I could see the stream. VLCs and LIVE555 Proxy Server are in the same VLAN so there is no problem with firewall or filtering (I disabled firewall on all server and pc). I hope asking too much, and that you can help me. Regards Ognjen Milosavljevi?, MSc.E.E. CCNP JNCIS-ENT Network engineer cid:image003.jpg at 01CBFF60.46A43120 Belgrade University Computer Center Kumanovska 7 11000 Beograd Serbia Tel: +381-11-3031258 Fax: +381-11-3031259 Email: ognjenm at rcub.bg.ac.rs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1497 bytes Desc: not available URL: From finlayson at live555.com Thu Nov 14 09:04:27 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Nov 2013 09:04:27 -0800 Subject: [Live-devel] VLC and The LIVE555 Proxy Server In-Reply-To: <001b01cee15a$149c58e0$3dd50aa0$@rcub.bg.ac.rs> References: <001b01cee15a$149c58e0$3dd50aa0$@rcub.bg.ac.rs> Message-ID: <322C57CD-B03D-4E33-88AA-04605439A790@live555.com> > When I try to restream, rtsp stream from VLC, I get these messages on LIVE555 Proxy Server: > > ProxyRTSPClient["rtsp://XXX"]: RTSP "DESCRIBE" command failed; trying again in 1 seconds > Opening connection to YYY, port ZZZ... > ...Connection to server failed: Connection timed out [...] > Also I confirmed streaming from VLC with VLC on the other pc and it was working fine, I could see the stream. > > VLCs and LIVE555 Proxy Server are in the same VLAN so there is no problem with firewall or filtering (I disabled firewall on all server and pc). Sorry, but I can't explain this. VLC (when used as a RTSP client) uses our RTSP client implementation - as does the "LIVE555 Proxy Server" - so I don't understand why the proxy server would be failing to connect to the 'back-end' server, but VLC succeeds. What happens when you try connecting to the stream using our "testRTSPClient" or "openRTSP" demo applications? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.desjardins at weather.com Thu Nov 14 11:16:07 2013 From: dan.desjardins at weather.com (Dan Desjardins) Date: Thu, 14 Nov 2013 13:16:07 -0600 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port Message-ID: I have successfully compiles the LIVE555ProxyServer and it works great with one exception. If I attempt to proxy a stream that originates on a port other than 554 it does not appear to work. My command line is: live555proxyserver -u username password rtsp://:9494/axis-media/media.amp?streamprofile=Balanced The proxyserver indicates that I can "Play this stream using the URL: rtsp:///proxyStream But vlc never successfully connects. I can connect to the rtsp stream directly with vlc (though it takes about 12 seconds to connect) but the connection through the proxy appears to time out. Here are the error messages I get: ProxyServerMediaSession["rtsp://**:9494/axis-media/media.amp/"] added new "ProxyServerMediaSubsession" for RTP/video/H264 track ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 3001992683) ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 1100823848) ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() If it is just a timeout issue can I extend the timeout? Where would I do that? * Dan **Desjardins *| *senior technology manager* * w:* 608 236 4399 *e:* dan.desjardins at weather.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Nov 14 12:27:54 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Nov 2013 12:27:54 -0800 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port In-Reply-To: References: Message-ID: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> > I have successfully compiles the LIVE555ProxyServer and it works great with one exception. If I attempt to proxy a stream that originates on a port other than 554 it does not appear to work. That's strange; I wonder if it could be a firewall problem? I.e., maybe you have a firewall - sitting between the proxy server and the back-end server - that is blocking UDP packets? But that wouldn't explain the problem if the *only* difference between a working back-end server and a non-working back-end server is its port number. But I suspect that - in reality - the RTSP port number is *not* the only difference between these two streams :-) Does the "DESCRIBE" command - sent from the proxy server to the back-end server - still work successfully when the back-end server uses a port other than 554? > I can connect to the rtsp stream directly with vlc (though it takes about 12 seconds to connect) This suggests that you do, indeed, have a problem with receiving UDP (because VLC works by first requesting regular RTP-over-UDP streaming, and then - if it fails to receive packets within several seconds - requesting RTP-over-TCP streaming instead; that would explain the long delay). To test this: NOTE TO EVERYONE: If you want to test a RTSP stream, you should do so first using our client applications: "testRTSPClient" and/or "openRTSP". Only after you have gotten those to work should you then try using VLC. (VLC is not our software.) Try running "openRTSP -n rtsp://:9494/axis-media/media.amp", and see whether it reports that "Data packets have begun arriving". If it doesn't, then try again, but this time adding the "-t" option to "openRTSP" (to request RTP-over-TCP streaming). If the "-t" option to "openRTSP" works, then the "LIVE555 Proxy Server" should also work (with this back-end stream) if you give it the "-t" option also. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.desjardins at weather.com Thu Nov 14 13:28:46 2013 From: dan.desjardins at weather.com (Dan Desjardins) Date: Thu, 14 Nov 2013 15:28:46 -0600 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port In-Reply-To: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> References: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> Message-ID: Perfect - yes the openrtsp.exe was able to open the stream from the camera on the alternate port without any problem at all. I went ahead and added the -t to the proxy stream and tried again in VLC and it immediately opened. I was worried because my receiver/decoder (providing HDSDI output with genlock) is actually VLC based. This works a treat! Thanks for your help! Des * Dan **Desjardins *| *senior technology manager* * w:* 608 236 4399 *e:* dan.desjardins at weather.com On Thu, Nov 14, 2013 at 2:27 PM, Ross Finlayson wrote: > I have successfully compiles the LIVE555ProxyServer and it works great > with one exception. If I attempt to proxy a stream that originates on a > port other than 554 it does not appear to work. > > > That's strange; I wonder if it could be a firewall problem? I.e., maybe > you have a firewall - sitting between the proxy server and the back-end > server - that is blocking UDP packets? But that wouldn't explain the > problem if the *only* difference between a working back-end server and a > non-working back-end server is its port number. But I suspect that - in > reality - the RTSP port number is *not* the only difference between these > two streams :-) > > Does the "DESCRIBE" command - sent from the proxy server to the back-end > server - still work successfully when the back-end server uses a port other > than 554? > > > I can connect to the rtsp stream directly with vlc (though it takes about > 12 seconds to connect) > > > This suggests that you do, indeed, have a problem with receiving UDP > (because VLC works by first requesting regular RTP-over-UDP streaming, and > then - if it fails to receive packets within several seconds - requesting > RTP-over-TCP streaming instead; that would explain the long delay). > > To test this: > > NOTE TO EVERYONE: If you want to test a RTSP stream, you should do so > first using our client applications: "testRTSPClient" and/or "openRTSP". > Only after you have gotten those to work should you then try using VLC. > (VLC is not our software.) > > Try running "openRTSP -n rtsp://:9494/axis-media/media.amp", > and see whether it reports that "Data packets have begun arriving". If it > doesn't, then try again, but this time adding the "-t" option to "openRTSP" > (to request RTP-over-TCP streaming). > > If the "-t" option to "openRTSP" works, then the "LIVE555 Proxy Server" > should also work (with this back-end stream) if you give it the "-t" option > also. > > > 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 Thu Nov 14 15:04:56 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Nov 2013 15:04:56 -0800 Subject: [Live-devel] Multiple session in Live555 In-Reply-To: References: Message-ID: <29299CA2-BB39-439D-89D4-EEEFFA504DD2@live555.com> > I am using your test app "testOndemandRtspServer",i want to know that > how its maintain multiple clients session internally. > is it create multiple process?? No. The application - like most LIVE555-based applications - uses a single-threaded event loop. See http://www.live555.com/liveMedia/faq.html#control-flow Our RTSP server implementation supports multiple concurrent clients by maintaining a separate "RTSPServer::RTSPClientSession" object for each client. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Nov 14 15:15:10 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Nov 2013 15:15:10 -0800 Subject: [Live-devel] Allow access to RTPSink when ServerMediaSubsession is overired In-Reply-To: <10632_1384422008_52849A78_10632_9993_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDA31B5@THSONEA01CMS01P.one.grp> References: <10632_1384422008_52849A78_10632_9993_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDA31B5@THSONEA01CMS01P.one.grp> Message-ID: <1D0A95D0-C7B1-44CC-A438-A92141EA2E59@live555.com> > Then, do you think it could be possible to reduce the privacy of ServerMediaSubsession::fRTPSink and define it as protected ? No - because there's no such member variable! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre8525 at hotmail.com Thu Nov 14 06:00:43 2013 From: andre8525 at hotmail.com (Andrew Andonopoulos) Date: Thu, 14 Nov 2013 16:00:43 +0200 Subject: [Live-devel] Current directory Message-ID: Hi to all, I have an Ubuntu machine which i installed the live555 media server and now is up an running: >From the nmap i can see the port 554/tcp and 8000/tcp open and the live555MediaServer process running.My question is, where i should put the file which i want to stream? In the instructions they write "current directory" but i have the the following: /usr/lib/live/mediaServer/live555MediaServer/usr/bin/live555MediaServer Another question is if someone manage to use the live555 with he BeeSmart middleware (for the VoD server only). Thank youAndrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Fri Nov 15 02:25:23 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Fri, 15 Nov 2013 11:25:23 +0100 Subject: [Live-devel] Allow access to RTPSink when ServerMediaSubsession is overired In-Reply-To: <1D0A95D0-C7B1-44CC-A438-A92141EA2E59@live555.com> References: <10632_1384422008_52849A78_10632_9993_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDA31B5@THSONEA01CMS01P.one.grp> <1D0A95D0-C7B1-44CC-A438-A92141EA2E59@live555.com> Message-ID: <14639_1384511125_5285F695_14639_1367_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDDE7FF@THSONEA01CMS01P.one.grp> Hi Ross, Sorry I didn't check where was the member. The fRTPSink I would like to access is in OnDemandServerMediaSubsession::fRTPSink (a similar member is in PassiveServerMediaSubsession::fRTPSink). By now I did not understand a problem that occurs randomly. Shortly we try to stop a FramedSource (calling FramedSource::handleCloser) that feed a Framer that feed an RTPSink but after this a task call MultiFramedRTPSink::sendNext use what was released. I will post on the subject when my ideas will be clearer. 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? : vendredi 15 novembre 2013 00:15 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Allow access to RTPSink when ServerMediaSubsession is overired Then, do you think it could be possible to reduce the privacy of ServerMediaSubsession::fRTPSink and define it as protected ? No - because there's no such member variable! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ognjenm at rcub.bg.ac.rs Fri Nov 15 04:03:08 2013 From: ognjenm at rcub.bg.ac.rs (=?iso-8859-2?Q?Ognjen_Milosavljevi=E6?=) Date: Fri, 15 Nov 2013 13:03:08 +0100 Subject: [Live-devel] live-devel Digest, Vol 121, Issue 12 In-Reply-To: References: Message-ID: <002d01cee1fa$a69f1480$f3dd3d80$@rcub.bg.ac.rs> Hi, Thank for replay. Comments are in line. > -----Original Message----- > From: live-devel-bounces at ns.live555.com [mailto:live-devel- > bounces at ns.live555.com] On Behalf Of live-devel-request at ns.live555.com > Sent: 14. novembar 2013 22:29 > To: live-devel at ns.live555.com > Subject: live-devel Digest, Vol 121, Issue 12 > > Send live-devel mailing list submissions to > live-devel at lists.live555.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.live555.com/mailman/listinfo/live-devel > or, via email, send a message with subject or body 'help' to > live-devel-request at lists.live555.com > > You can reach the person managing the list at > live-devel-owner at lists.live555.com > > When replying, please edit your Subject line so it is more specific than "Re: > Contents of live-devel digest..." > > > Today's Topics: > > 1. Re: VLC and The LIVE555 Proxy Server (Ross Finlayson) > 2. Unable to proxy an rtsp stream on alternate port (Dan Desjardins) > 3. Re: Unable to proxy an rtsp stream on alternate port > (Ross Finlayson) > 4. Re: Unable to proxy an rtsp stream on alternate port > (Dan Desjardins) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 14 Nov 2013 09:04:27 -0800 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] VLC and The LIVE555 Proxy Server > Message-ID: <322C57CD-B03D-4E33-88AA-04605439A790 at live555.com> > Content-Type: text/plain; charset="iso-8859-2" > > > When I try to restream, rtsp stream from VLC, I get these messages on > LIVE555 Proxy Server: > > > > ProxyRTSPClient["rtsp://XXX"]: RTSP "DESCRIBE" command failed; trying > > again in 1 seconds Opening connection to YYY, port ZZZ... > > ...Connection to server failed: Connection timed out > [...] > > Also I confirmed streaming from VLC with VLC on the other pc and it was > working fine, I could see the stream. > > > > VLCs and LIVE555 Proxy Server are in the same VLAN so there is no > problem with firewall or filtering (I disabled firewall on all server and pc). > > Sorry, but I can't explain this. VLC (when used as a RTSP client) uses our > RTSP client implementation - as does the "LIVE555 Proxy Server" - so I don't > understand why the proxy server would be failing to connect to the 'back- > end' server, but VLC succeeds. > > What happens when you try connecting to the stream using our > "testRTSPClient" or "openRTSP" demo applications? [OM] Here are the outputs: ./testRTSPClient rtsp://X:Y/stream Opening connection to X, port Y... ...Connection to server failed: Connection timed out [URL:"rtsp://X:Y/stream"]: Failed to get a SDP description: Connection to server failed: Connection timed out [URL:"rtsp://X:Y/stream"]: Closing the stream. ./openRTSP rtsp://X:Y/stream Opening connection to X, port Y... ...Connection to server failed: Connection timed out Opening connection to X, port Y... ...Connection to server failed: Connection timed out Failed to get a SDP description for the URL "rtsp://X:Y/stream": Connection to server failed: Connection timed out X is beck-end server IP address, Y port. I am using VLC 2.0.8 as backend server. Regards, Ognjen > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: devel/attachments/20131114/77ebd8a8/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 14 Nov 2013 13:16:07 -0600 > From: Dan Desjardins > To: live-devel at ns.live555.com > Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port > Message-ID: > .gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > I have successfully compiles the LIVE555ProxyServer and it works great with > one exception. If I attempt to proxy a stream that originates on a port > other than 554 it does not appear to work. > My command line is: > > live555proxyserver -u username password rtsp:// address>:9494/axis-media/media.amp?streamprofile=Balanced > > The proxyserver indicates that I can "Play this stream using the URL: > rtsp:///proxyStream > > But vlc never successfully connects. I can connect to the rtsp stream > directly with vlc (though it takes about 12 seconds to connect) but the > connection through the proxy appears to time out. Here are the error > messages I get: > > ProxyServerMediaSession["rtsp://**:9494/axis- > media/media.amp/"] > added > new "ProxyServerMediaSubsession" for RTP/video/H264 track > ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id > 0) > Initiated: ProxyServerMediaSubsession["H264"] > ProxyServerMediaSubsession["H264"]::createNewRTPSink() > ProxyServerMediaSubsession["H264"]::closeStreamSource() > ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id > 3001992683) > > ProxyServerMediaSubsession["H264"]::createNewRTPSink() > ProxyServerMediaSubsession["H264"]::closeStreamSource() > ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id > 1100823848) > > ProxyServerMediaSubsession["H264"]::createNewRTPSink() > ProxyServerMediaSubsession["H264"]::closeStreamSource() > > If it is just a timeout issue can I extend the timeout? Where would I do > that? > > * Dan **Desjardins *| *senior technology manager* > * w:* 608 236 4399 *e:* dan.desjardins at weather.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: devel/attachments/20131114/50292382/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Thu, 14 Nov 2013 12:27:54 -0800 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] Unable to proxy an rtsp stream on alternate > port > Message-ID: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C at live555.com> > Content-Type: text/plain; charset="iso-8859-1" > > > I have successfully compiles the LIVE555ProxyServer and it works great > with one exception. If I attempt to proxy a stream that originates on a port > other than 554 it does not appear to work. > > That's strange; I wonder if it could be a firewall problem? I.e., maybe you > have a firewall - sitting between the proxy server and the back-end server - > that is blocking UDP packets? But that wouldn't explain the problem if the > *only* difference between a working back-end server and a non-working > back-end server is its port number. But I suspect that - in reality - the RTSP > port number is *not* the only difference between these two streams :-) > > Does the "DESCRIBE" command - sent from the proxy server to the back-end > server - still work successfully when the back-end server uses a port other > than 554? > > > > I can connect to the rtsp stream directly with vlc (though it takes > > about 12 seconds to connect) > > This suggests that you do, indeed, have a problem with receiving UDP > (because VLC works by first requesting regular RTP-over-UDP streaming, and > then - if it fails to receive packets within several seconds - requesting RTP- > over-TCP streaming instead; that would explain the long delay). > > To test this: > > NOTE TO EVERYONE: If you want to test a RTSP stream, you should do so > first using our client applications: "testRTSPClient" and/or "openRTSP". > Only after you have gotten those to work should you then try using VLC. > (VLC is not our software.) > > Try running "openRTSP -n rtsp://:9494/axis-media/media.amp", > and see whether it reports that "Data packets have begun arriving". If it > doesn't, then try again, but this time adding the "-t" option to "openRTSP" > (to request RTP-over-TCP streaming). > > If the "-t" option to "openRTSP" works, then the "LIVE555 Proxy Server" > should also work (with this back-end stream) if you give it the "-t" option > also. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: devel/attachments/20131114/999f34d7/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Thu, 14 Nov 2013 15:28:46 -0600 > From: Dan Desjardins > To: "LIVE555 Streaming Media - development & use" > > Subject: Re: [Live-devel] Unable to proxy an rtsp stream on alternate > port > Message-ID: > _WQKH+GKmutg at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Perfect - yes the openrtsp.exe was able to open the stream from the camera > on the alternate port without any problem at all. I went ahead and added > the -t to the proxy stream and tried again in VLC and it immediately opened. > I was worried because my receiver/decoder (providing HDSDI output with > genlock) is actually VLC based. This works a treat! > Thanks for your help! > > Des > > > * Dan **Desjardins *| *senior technology manager* > * w:* 608 236 4399 *e:* dan.desjardins at weather.com > > > > On Thu, Nov 14, 2013 at 2:27 PM, Ross Finlayson > wrote: > > > I have successfully compiles the LIVE555ProxyServer and it works great > > with one exception. If I attempt to proxy a stream that originates on a > > port other than 554 it does not appear to work. > > > > > > That's strange; I wonder if it could be a firewall problem? I.e., > > maybe you have a firewall - sitting between the proxy server and the > > back-end server - that is blocking UDP packets? But that wouldn't > > explain the problem if the *only* difference between a working > > back-end server and a non-working back-end server is its port number. > > But I suspect that - in reality - the RTSP port number is *not* the > > only difference between these two streams :-) > > > > Does the "DESCRIBE" command - sent from the proxy server to the > > back-end server - still work successfully when the back-end server > > uses a port other than 554? > > > > > > I can connect to the rtsp stream directly with vlc (though it takes > > about > > 12 seconds to connect) > > > > > > This suggests that you do, indeed, have a problem with receiving UDP > > (because VLC works by first requesting regular RTP-over-UDP streaming, > > and then - if it fails to receive packets within several seconds - > > requesting RTP-over-TCP streaming instead; that would explain the long > delay). > > > > To test this: > > > > NOTE TO EVERYONE: If you want to test a RTSP stream, you should do so > > first using our client applications: "testRTSPClient" and/or "openRTSP". > > Only after you have gotten those to work should you then try using VLC. > > (VLC is not our software.) > > > > Try running "openRTSP -n rtsp:// > address>:9494/axis-media/media.amp", > > and see whether it reports that "Data packets have begun arriving". > > If it doesn't, then try again, but this time adding the "-t" option to > "openRTSP" > > (to request RTP-over-TCP streaming). > > > > If the "-t" option to "openRTSP" works, then the "LIVE555 Proxy Server" > > should also work (with this back-end stream) if you give it the "-t" > > option also. > > > > > > 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: devel/attachments/20131114/afc2fa28/attachment.html> > > ------------------------------ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > End of live-devel Digest, Vol 121, Issue 12 > ******************************************* From finlayson at live555.com Fri Nov 15 04:19:52 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 15 Nov 2013 04:19:52 -0800 Subject: [Live-devel] VLC and The LIVE555 Proxy Server In-Reply-To: <002d01cee1fa$a69f1480$f3dd3d80$@rcub.bg.ac.rs> References: <002d01cee1fa$a69f1480$f3dd3d80$@rcub.bg.ac.rs> Message-ID: > Comments are in line. OK, but you didn't trim the (large!) parts of the email digest that weren't appropriate! And you didn't fix the "Subject:" line in your response (I fixed it for you). (Because of this, future postings from you will be moderated.) Please everybody, use common sense when replying to email digests. >> What happens when you try connecting to the stream using our >> "testRTSPClient" or "openRTSP" demo applications? > [OM] Here are the outputs: > ./testRTSPClient rtsp://X:Y/stream > Opening connection to X, port Y... > ...Connection to server failed: Connection timed out > [URL:"rtsp://X:Y/stream"]: Failed to get a SDP description: Connection to > server failed: Connection timed out > [URL:"rtsp://X:Y/stream"]: Closing the stream. > > ./openRTSP rtsp://X:Y/stream > Opening connection to X, port Y... > ...Connection to server failed: Connection timed out > Opening connection to X, port Y... > ...Connection to server failed: Connection timed out > Failed to get a SDP description for the URL "rtsp://X:Y/stream": Connection > to server failed: Connection timed out > > X is beck-end server IP address, Y port. I am using VLC 2.0.8 as backend > server. For some reason, the back-end server is not handling incoming connections on port 'Y'. Unfortunately we can't help you figure out why (because VLC is not our software, and it doesn't use our library when implementing a RTSP server). If you're sure that the server address and port number are correct, then I suggest asking a VLC mailing list for help. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 15 04:23:00 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 15 Nov 2013 04:23:00 -0800 Subject: [Live-devel] Current directory In-Reply-To: References: Message-ID: <0BF5D7E0-FB52-4C4E-933A-A091AF0601ED@live555.com> > My question is, where i should put the file which i want to stream? In the instructions they write "current directory" but i have the the following: > > /usr/lib/live/mediaServer/live555MediaServer > /usr/bin/live555MediaServer The "current directory" is exactly that - the directory that you're in when you run the "live555MediaServer" command (presuming that you're doing so from a command line). > Another question is if someone manage to use the live555 with he BeeSmart middleware (for the VoD server only). I don't know, but if the company that develops that system were to contact me, then I might be able to help them do this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 15 04:46:57 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 15 Nov 2013 04:46:57 -0800 Subject: [Live-devel] Allow access to RTPSink when ServerMediaSubsession is overired In-Reply-To: <14639_1384511125_5285F695_14639_1367_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDDE7FF@THSONEA01CMS01P.one.grp> References: <10632_1384422008_52849A78_10632_9993_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDA31B5@THSONEA01CMS01P.one.grp> <1D0A95D0-C7B1-44CC-A438-A92141EA2E59@live555.com> <14639_1384511125_5285F695_14639_1367_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDDE7FF@THSONEA01CMS01P.one.grp> Message-ID: > Sorry I didn?t check where was the member. > The fRTPSink I would like to access is in OnDemandServerMediaSubsession::fRTPSink Actually, it's not there either. "fRTPSink" is a member of the "StreamState" class. But I'm not going to expose this, because the creation/destruction of the (possibly multiple) "RTPSink" objects (and the corresponding (possibly multiple) "StreamState" objects) occur dynamically - under the control of the RTSPServer - as (possibly multiple) clients connect to/disconnect from the server. This is not something that a "OnDemandServerMediaSubsession" (subclass) object should ever be aware of, because the "(OnDemand)ServerMediaSubsession" object refers to the source media stream as a whole - regardless of who and how many clients are currently receiving it. > By now I did not understand a problem that occurs randomly. > Shortly we try to stop a FramedSource (calling FramedSource::handleCloser) that feed a Framer that feed an RTPSink but after this a task call MultiFramedRTPSink::sendNext use what was released. I think I know what the problem is! I've just released a new version (2013.11.15) that, I believe, will fix this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbischan at watchtower-security.com Fri Nov 15 06:26:01 2013 From: bbischan at watchtower-security.com (Bob Bischan) Date: Fri, 15 Nov 2013 08:26:01 -0600 Subject: [Live-devel] Allow access to RTPSink when ServerMediaSubsession is overired In-Reply-To: References: <10632_1384422008_52849A78_10632_9993_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDA31B5@THSONEA01CMS01P.one.grp> <1D0A95D0-C7B1-44CC-A438-A92141EA2E59@live555.com> <14639_1384511125_5285F695_14639_1367_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDDE7FF@THSONEA01CMS01P.one.grp> Message-ID: Ross, Can you verify 2013.11.15 is uploaded? I see changelog entries, but current appears to be *live.2013.11.14.tar.gz.* Thanks, Bob On Fri, Nov 15, 2013 at 6:46 AM, Ross Finlayson wrote: > Sorry I didn?t check where was the member. > The fRTPSink I would like to access is in > OnDemandServerMediaSubsession::fRTPSink > > > Actually, it's not there either. "fRTPSink" is a member of the > "StreamState" class. > > But I'm not going to expose this, because the creation/destruction of the > (possibly multiple) "RTPSink" objects (and the corresponding (possibly > multiple) "StreamState" objects) occur dynamically - under the control of > the RTSPServer - as (possibly multiple) clients connect to/disconnect from > the server. This is not something that a "OnDemandServerMediaSubsession" > (subclass) object should ever be aware of, because the > "(OnDemand)ServerMediaSubsession" object refers to the source media stream > as a whole - regardless of who and how many clients are currently receiving > it. > > > By now I did not understand a problem that occurs randomly. > Shortly we try to stop a FramedSource (calling FramedSource::handleCloser) > that feed a Framer that feed an RTPSink but after this a task call > MultiFramedRTPSink::sendNext use what was released. > > > I think I know what the problem is! I've just released a new version > (2013.11.15) that, I believe, will fix this. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 15 10:29:56 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 15 Nov 2013 10:29:56 -0800 Subject: [Live-devel] Allow access to RTPSink when ServerMediaSubsession is overired In-Reply-To: References: <10632_1384422008_52849A78_10632_9993_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDA31B5@THSONEA01CMS01P.one.grp> <1D0A95D0-C7B1-44CC-A438-A92141EA2E59@live555.com> <14639_1384511125_5285F695_14639_1367_1_1BE8971B6CFF3A4F97AF4011882AA25501563EDDE7FF@THSONEA01CMS01P.one.grp> Message-ID: <1B085C8A-4690-4434-B236-AF7A68927A72@live555.com> > Can you verify 2013.11.15 is uploaded? I see changelog entries, but current appears to be live.2013.11.14.tar.gz. Oops - my mistake. Thanks for letting me know; it's installed now. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Fri Nov 15 12:24:06 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Fri, 15 Nov 2013 13:24:06 -0700 Subject: [Live-devel] rtsp proxy stops streaming In-Reply-To: <1CB4FEF9-EE1B-4CCC-9DC1-85BBC6BA8F93@live555.com> References: <528401B3.8060504@vivint.com> <1CB4FEF9-EE1B-4CCC-9DC1-85BBC6BA8F93@live555.com> Message-ID: <528682E6.7090405@vivint.com> I'm still working on duplicating what I saw and will capture logs and post once I do. So far I have not seen a drop of the streaming data. Thanks, Craig On 11/13/2013 04:06 PM, Ross Finlayson wrote: I'm wondering if there is a specific message I can look for in the logs when at level 2 that will indicate if a proxies stream has failed? I'm using the proxyServer example and at times the stream stops streaming. I can see the OPTION commands going out to the camera with a response, but connecting a client to the proxied stream does not work. Not sure if it is due to loosing a connection, but what I find strange is the OPTION command appears to respond. Is there something in the response of the OPTION that indicates a problem? I'm not sure. Why don't you post the diagnostic output (from the proxy server) around the time that "connecting a client to the proxied stream does not work"? (And also, please clarify what "does not work" means). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at subfocal.net Sat Nov 16 04:57:51 2013 From: mike at subfocal.net (Mike Mueller) Date: Sat, 16 Nov 2013 04:57:51 -0800 Subject: [Live-devel] Coping with a buggy IP camera Message-ID: Hi folks, I recently picked up a Foscam FI9821W V2 and upgraded it to the current v1.11.1.18 firmware, and I'm still having difficulty streaming from it with any open source tools. (For example, VLC plays it, but has a lot of errors, visible corruption, and high latency.) In my extensive searching, I found this thread where Ross points out that the camera's RTSP server is broken: http://lists.live555.com/pipermail/live-devel/2013-April/016863.html (I also came across a mini-rant from Ross about the firmware devs' lack of interest in participating or getting support here, with which I agree...) I know a true workaround is impossible, but if I wanted to get really dirty and hack up the client code with hard-coded video params, would I be able to make the stream play correctly? Has anyone tried this? Or anyone know what changes I'd need to make? Background: I'm interested in playing with computer vision using this camera, and step one is getting live555 to cleanly decode the H.264 frames... If I can't actually decode this camera's video, then it was basically a waste of money. :( Any help would be appreciated. Thanks! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Nov 16 08:45:34 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Nov 2013 08:45:34 -0800 Subject: [Live-devel] Coping with a buggy IP camera In-Reply-To: References: Message-ID: > Any help would be appreciated. The only party that can 'help' is Foscam. They need to fix their camera. Thank you for prodding them about this on their forum (I presume that "machrider" is you). But if they continue to drag their feet on this, I suggest you take your business elsewhere. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 17 11:38:27 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 17 Nov 2013 12:38:27 -0700 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port In-Reply-To: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> References: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> Message-ID: <52891B33.9060609@vivint.com> I apologize for the last post being so big and the duplicate posting, I moved the log output to pastebin. Ok, I have managed to create the problem where a working camera providing an RTSP stream to the rtsp proxy does not work via the proxy. I downloaded the latest code and compiled it on my laptop and setup the proxy to use the cameras providing my RTSP streams. I tested the proxy stream using gstreamers playbin2 (this has always worked for me) and vlc. Both failed to display my camera. I have other streams setup on the proxy server with the same model of cameras that work great with both playbin2 and vlc. I tried the openRTSP test, but wasn't sure what the expected output should be. (I paste it below). Here is the log out using -V http://pastebin.com/XtM2zHjd OUTPUT FROM oepnRTSP craig at craig-ThinkPad-W530:~/hg/live555-new/testProgs$ ./openRTSP -V rtsp://172.16.10.101:8554/proxyStream-4 Opened URL "rtsp://172.16.10.101:8554/proxyStream-4", returning a SDP description: v=0 o=- 1384715305499911 1 IN IP4 172.16.10.101 s=LIVE555 Streaming Media v2013.11.15 i=LIVE555 Streaming Media v2013.11.15 t=0 0 a=tool:LIVE555 Streaming Media v2013.11.15 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.11.15 a=x-qt-text-inf:LIVE555 Streaming Media v2013.11.15 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64401F;sprop-parameter-sets=J2RAH6wsagFAFumoKDAqAAAH0gAB1MAo,KO4EYsA= a=control:track1 Created receiver for "video/H264" subsession (client ports 40540-40541) Setup "video/H264" subsession (client ports 40540-40541) Created output file: "video-H264-1" Started playing session Receiving streamed data (signal with "kill -HUP 13953" or "kill -USR1 13953" to terminate)... Thanks, Craig On 11/13/2013 04:06 PM, Ross Finlayson wrote: I'm wondering if there is a specific message I can look for in the logs when at level 2 that will indicate if a proxies stream has failed? I'm using the proxyServer example and at times the stream stops streaming. I can see the OPTION commands going out to the camera with a response, but connecting a client to the proxied stream does not work. Not sure if it is due to loosing a connection, but what I find strange is the OPTION command appears to respond. Is there something in the response of the OPTION that indicates a problem? I'm not sure. Why don't you post the diagnostic output (from the proxy server) around the time that "connecting a client to the proxied stream does not work"? (And also, please clarify what "does not work" means). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 17 13:23:14 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 17 Nov 2013 14:23:14 -0700 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port In-Reply-To: <52891B33.9060609@vivint.com> References: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> <52891B33.9060609@vivint.com> Message-ID: <528933C2.5060308@vivint.com> If it helps here is the commandline I ran and proxy in question: ./live555ProxyServer -V rtsp://172.16.10.106:554/live.sdp rtsp://172.16.10.113:554/live.sdp rtsp://172.16.10.110:554/live.sdp rtsp://172.16.10.112:554/live.sdp rtsp://172.16.10.105:554/live.sdp rtsp://172.16.10.102:554/Video-0 rtsp://172.16.10.109:554/live.sdp RTSP stream, proxying the stream "rtsp://172.16.10.112:554/live.sdp" on rtsp://172.16.10.101:8554/proxyStream-4 On 11/17/2013 12:38 PM, Craig Matsuura wrote: I apologize for the last post being so big and the duplicate posting, I moved the log output to pastebin. Ok, I have managed to create the problem where a working camera providing an RTSP stream to the rtsp proxy does not work via the proxy. I downloaded the latest code and compiled it on my laptop and setup the proxy to use the cameras providing my RTSP streams. I tested the proxy stream using gstreamers playbin2 (this has always worked for me) and vlc. Both failed to display my camera. I have other streams setup on the proxy server with the same model of cameras that work great with both playbin2 and vlc. I tried the openRTSP test, but wasn't sure what the expected output should be. (I paste it below). Here is the log out using -V http://pastebin.com/XtM2zHjd OUTPUT FROM oepnRTSP craig at craig-ThinkPad-W530:~/hg/live555-new/testProgs$ ./openRTSP -V rtsp://172.16.10.101:8554/proxyStream-4 Opened URL "rtsp://172.16.10.101:8554/proxyStream-4", returning a SDP description: v=0 o=- 1384715305499911 1 IN IP4 172.16.10.101 s=LIVE555 Streaming Media v2013.11.15 i=LIVE555 Streaming Media v2013.11.15 t=0 0 a=tool:LIVE555 Streaming Media v2013.11.15 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.11.15 a=x-qt-text-inf:LIVE555 Streaming Media v2013.11.15 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64401F;sprop-parameter-sets=J2RAH6wsagFAFumoKDAqAAAH0gAB1MAo,KO4EYsA= a=control:track1 Created receiver for "video/H264" subsession (client ports 40540-40541) Setup "video/H264" subsession (client ports 40540-40541) Created output file: "video-H264-1" Started playing session Receiving streamed data (signal with "kill -HUP 13953" or "kill -USR1 13953" to terminate)... Thanks, Craig On 11/13/2013 04:06 PM, Ross Finlayson wrote: I'm wondering if there is a specific message I can look for in the logs when at level 2 that will indicate if a proxies stream has failed? I'm using the proxyServer example and at times the stream stops streaming. I can see the OPTION commands going out to the camera with a response, but connecting a client to the proxied stream does not work. Not sure if it is due to loosing a connection, but what I find strange is the OPTION command appears to respond. Is there something in the response of the OPTION that indicates a problem? I'm not sure. Why don't you post the diagnostic output (from the proxy server) around the time that "connecting a client to the proxied stream does not work"? (And also, please clarify what "does not work" means). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 17 13:29:09 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 17 Nov 2013 14:29:09 -0700 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port In-Reply-To: <52891B33.9060609@vivint.com> References: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> <52891B33.9060609@vivint.com> Message-ID: <52893525.3030408@vivint.com> Sorry, to keep posting. I think the problem is due to the 400 Bad response from the Setup. This would be a problem on the camera we use and not honoring the OPTION command keepalive. I'l check into this an report back. Thanks, Craig On 11/17/2013 12:38 PM, Craig Matsuura wrote: I apologize for the last post being so big and the duplicate posting, I moved the log output to pastebin. Ok, I have managed to create the problem where a working camera providing an RTSP stream to the rtsp proxy does not work via the proxy. I downloaded the latest code and compiled it on my laptop and setup the proxy to use the cameras providing my RTSP streams. I tested the proxy stream using gstreamers playbin2 (this has always worked for me) and vlc. Both failed to display my camera. I have other streams setup on the proxy server with the same model of cameras that work great with both playbin2 and vlc. I tried the openRTSP test, but wasn't sure what the expected output should be. (I paste it below). Here is the log out using -V http://pastebin.com/XtM2zHjd OUTPUT FROM oepnRTSP craig at craig-ThinkPad-W530:~/hg/live555-new/testProgs$ ./openRTSP -V rtsp://172.16.10.101:8554/proxyStream-4 Opened URL "rtsp://172.16.10.101:8554/proxyStream-4", returning a SDP description: v=0 o=- 1384715305499911 1 IN IP4 172.16.10.101 s=LIVE555 Streaming Media v2013.11.15 i=LIVE555 Streaming Media v2013.11.15 t=0 0 a=tool:LIVE555 Streaming Media v2013.11.15 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.11.15 a=x-qt-text-inf:LIVE555 Streaming Media v2013.11.15 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64401F;sprop-parameter-sets=J2RAH6wsagFAFumoKDAqAAAH0gAB1MAo,KO4EYsA= a=control:track1 Created receiver for "video/H264" subsession (client ports 40540-40541) Setup "video/H264" subsession (client ports 40540-40541) Created output file: "video-H264-1" Started playing session Receiving streamed data (signal with "kill -HUP 13953" or "kill -USR1 13953" to terminate)... Thanks, Craig On 11/13/2013 04:06 PM, Ross Finlayson wrote: I'm wondering if there is a specific message I can look for in the logs when at level 2 that will indicate if a proxies stream has failed? I'm using the proxyServer example and at times the stream stops streaming. I can see the OPTION commands going out to the camera with a response, but connecting a client to the proxied stream does not work. Not sure if it is due to loosing a connection, but what I find strange is the OPTION command appears to respond. Is there something in the response of the OPTION that indicates a problem? I'm not sure. Why don't you post the diagnostic output (from the proxy server) around the time that "connecting a client to the proxied stream does not work"? (And also, please clarify what "does not work" means). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Nov 17 21:32:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 17 Nov 2013 21:32:43 -0800 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port In-Reply-To: <52893525.3030408@vivint.com> References: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> <52891B33.9060609@vivint.com> <52893525.3030408@vivint.com> Message-ID: > Sorry, to keep posting. I think the problem is due to the 400 Bad response from the Setup. Yes, and I'm totally confused - because this is the *exact same problem* that you reported two weeks ago. The conclusion at that time was that this was due to a bug in your back-end server (a 'Vivotek' network camera). The solution to this problem (and the only one that I will consider, unless I hear directly from 'Vovotek') is to get Vivotek to fix their cameras. So I don't understand why you are continuing to report this problem, which is a problem with the network camera; not our software. I'm also confused because - in your first message on this thread (and noted in the "Subject:" line) - you said that you were having a problem streaming from a back-end server that used a port number other than 554, but were not having any problem streaming from back-end servers (other than, presumably, Vivotek cameras) that used port 554. Yet all of the examples that you gave today used port 554. So, I think you need to start from scratch, and explain - clearly and specifically - exactly what your new problem is. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 17 21:51:38 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 17 Nov 2013 22:51:38 -0700 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port In-Reply-To: References: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> <52891B33.9060609@vivint.com> <52893525.3030408@vivint.com> Message-ID: <5289AAEA.6060107@vivint.com> I agree Ross. I apologize for the confusion I have been looking for away to duplicate the problem I saw and thought I had duplicated the problem. I did repost that I found out that the camera firmware was still out of date. Let's just call this thread dead and I will repost if and when I find a way to duplicate my problem. Thanks, Craig I'm working on a way to duplicate the issue I have seen. I'm sorry but I don't recall saying I could not stream from port 554, as I have been using 554 On 11/17/2013 10:32 PM, Ross Finlayson wrote: Sorry, to keep posting. I think the problem is due to the 400 Bad response from the Setup. Yes, and I'm totally confused - because this is the *exact same problem* that you reported two weeks ago. The conclusion at that time was that this was due to a bug in your back-end server (a 'Vivotek' network camera). The solution to this problem (and the only one that I will consider, unless I hear directly from 'Vovotek') is to get Vivotek to fix their cameras. So I don't understand why you are continuing to report this problem, which is a problem with the network camera; not our software. I'm also confused because - in your first message on this thread (and noted in the "Subject:" line) - you said that you were having a problem streaming from a back-end server that used a port number other than 554, but were not having any problem streaming from back-end servers (other than, presumably, Vivotek cameras) that used port 554. Yet all of the examples that you gave today used port 554. So, I think you need to start from scratch, and explain - clearly and specifically - exactly what your new problem is. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 17 21:53:48 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sun, 17 Nov 2013 22:53:48 -0700 Subject: [Live-devel] Proxy Server Debugging Message-ID: <5289AB6C.6090100@vivint.com> What is the best way to determine that a proxy server is streaming from an RTSP source? I see OPTION commands sent and responding using verbose logging, but this does not indicate to me that the stream is sending data? Thanks, Craig From finlayson at live555.com Sun Nov 17 21:54:50 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 17 Nov 2013 21:54:50 -0800 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port In-Reply-To: <5289AAEA.6060107@vivint.com> References: <0CD7ECC3-09F3-4AC8-A20E-A1CB00BB346C@live555.com> <52891B33.9060609@vivint.com> <52893525.3030408@vivint.com> <5289AAEA.6060107@vivint.com> Message-ID: <46B0C1C8-6ECB-43C2-ADC3-84D54EE8A650@live555.com> > I'm working on a way to duplicate the issue I have seen. I'm sorry but I don't recall saying I could not stream from port 554, as I have been using 554 No, you said just the opposite: > I have successfully compiles the LIVE555ProxyServer and it works great with one exception. If I attempt to proxy a stream that originates on a port other than 554 it does not appear to work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Nov 17 22:13:50 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 17 Nov 2013 22:13:50 -0800 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: <5289AB6C.6090100@vivint.com> References: <5289AB6C.6090100@vivint.com> Message-ID: > What is the best way to determine that a proxy server is streaming from > an RTSP source? The best way is to run, on the computer on which you would run the proxy server openRTSP -n rtsp:// (The "-n" option tells "openRTSP" to display a report (with a beep) when the first RTP packet arrives.) If "openRTSP" successfully receives data from the back-end server, then the "LIVE555 Proxy Server" - when run on the same stream - will also receive data (because both "openRTSP" and the "LIVE555 ProxyServer" use the same RTSP client code). (Unless, of course, the back-end server is a buggy 'Vivotek' camera, but you now know to stop using those :-) If, however, "openRTSP" fails to receive data from the back-end server, then the problem may be that the back-end server is behind a firewall that is blocking RTP/UDP packets. So instead, try requesting RTP/RTCP-over-TCP streaming, by adding the "-t" option to "openRTSP" - i.e. openRTSP -t -n rtsp:// If that works, then adding the "-t" option to the "live555ProxyServer" command line will also work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 17 23:08:52 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Mon, 18 Nov 2013 00:08:52 -0700 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: References: <5289AB6C.6090100@vivint.com> Message-ID: <5289BD04.70704@vivint.com> So I have verified the source device is streaming data. I have connected to it's RTSP stream directly, using gstreamer and vlc. I will connect the openRTSP to the source back-end when it fails and see if it works. Thanks, Craig On 11/17/2013 11:13 PM, Ross Finlayson wrote: What is the best way to determine that a proxy server is streaming from an RTSP source? The best way is to run, on the computer on which you would run the proxy server openRTSP -n rtsp:// (The "-n" option tells "openRTSP" to display a report (with a beep) when the first RTP packet arrives.) If "openRTSP" successfully receives data from the back-end server, then the "LIVE555 Proxy Server" - when run on the same stream - will also receive data (because both "openRTSP" and the "LIVE555 ProxyServer" use the same RTSP client code). (Unless, of course, the back-end server is a buggy 'Vivotek' camera, but you now know to stop using those :-) If, however, "openRTSP" fails to receive data from the back-end server, then the problem may be that the back-end server is behind a firewall that is blocking RTP/UDP packets. So instead, try requesting RTP/RTCP-over-TCP streaming, by adding the "-t" option to "openRTSP" - i.e. openRTSP -t -n rtsp:// If that works, then adding the "-t" option to the "live555ProxyServer" command line will also work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 17 23:13:06 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Mon, 18 Nov 2013 00:13:06 -0700 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: References: <5289AB6C.6090100@vivint.com> Message-ID: <5289BE02.4090102@vivint.com> On a side note, I gave Vivotek engineers the mailing list info and I hoped they would join. We are working directly with them and I will see them tomorrow. Thanks, Craig On 11/17/2013 11:13 PM, Ross Finlayson wrote: What is the best way to determine that a proxy server is streaming from an RTSP source? The best way is to run, on the computer on which you would run the proxy server openRTSP -n rtsp:// (The "-n" option tells "openRTSP" to display a report (with a beep) when the first RTP packet arrives.) If "openRTSP" successfully receives data from the back-end server, then the "LIVE555 Proxy Server" - when run on the same stream - will also receive data (because both "openRTSP" and the "LIVE555 ProxyServer" use the same RTSP client code). (Unless, of course, the back-end server is a buggy 'Vivotek' camera, but you now know to stop using those :-) If, however, "openRTSP" fails to receive data from the back-end server, then the problem may be that the back-end server is behind a firewall that is blocking RTP/UDP packets. So instead, try requesting RTP/RTCP-over-TCP streaming, by adding the "-t" option to "openRTSP" - i.e. openRTSP -t -n rtsp:// If that works, then adding the "-t" option to the "live555ProxyServer" command line will also work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sun Nov 17 23:22:15 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Mon, 18 Nov 2013 00:22:15 -0700 Subject: [Live-devel] Unable to proxy an rtsp stream on alternate port Message-ID: That comment was resolved So it is a good idea that this thread ends. Thanks, Craig Sent from my Verizon Wireless 4G LTE DROID Ross Finlayson wrote: I'm working on a way to duplicate the issue I have seen. I'm sorry but I don't recall saying I could not stream from port 554, as I have been using 554 No, you said just the opposite: I have successfully compiles the LIVE555ProxyServer and it works great with one exception. If I attempt to proxy a stream that originates on a port other than 554 it does not appear to work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Nov 17 23:48:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 17 Nov 2013 23:48:06 -0800 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: <5289BD04.70704@vivint.com> References: <5289AB6C.6090100@vivint.com> <5289BD04.70704@vivint.com> Message-ID: > So I have verified the source device is streaming data. I have connected to it's RTSP stream directly, using gstreamer and vlc. I will connect the openRTSP to the source back-end when it fails and see if it works. No! You should test your back-end stream using "openRTSP" *FIRST*, before using a media player. The reason for this is that media players usually do not give you a clear indication of what is going on. (For example, "VLC" automatically - behind the scenes - requests RTP/RTCP-over-TCP streaming if RTP-over-UDP streaming appears to fail. So you won't know whether or not you need to give the proxy server the "-t" option.) NOTE TO EVERYONE: When you're testing a RTSP stream to check whether it's available, "openRTSP" should be the *FIRST* thing that you try. Only then should you try using a media player. And it makes no sense to talk about "connecting openRTSP (or any other client) to a back-end stream when it fails", because that probably won't tell you anything. You'd be requesting a whole new session. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishnaks at iwavesystems.com Sun Nov 17 23:52:37 2013 From: krishnaks at iwavesystems.com (Krishna) Date: Mon, 18 Nov 2013 13:22:37 +0530 Subject: [Live-devel] Audio/Video Sink - Video stops in between Message-ID: HI Ross, I have a problem in Audio/Video sink. Video comes from camera and encoding to H.264 and audio comes directly from microphone (PCM 16-bit LE, Sampling frequency is 8k, mono(1 channel)). We are able to get Video, Audio sink with the minimal delay. Now the problem is Sometimes Video stops for a while (for some 500ms; I guess to make Sink) which I need to avoid. How I can avoid that? Regards, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Mon Nov 18 07:25:03 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Mon, 18 Nov 2013 08:25:03 -0700 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: References: <5289AB6C.6090100@vivint.com> <5289BD04.70704@vivint.com> Message-ID: <528A314F.5060109@vivint.com> After running openRTSP the last thing displayed is Data packets have begun arriving [#####], I did not here any beep. After browsing the source I found that the playCommon.cpp has this message and a \007, which apparently did not cause the beep (no big deal). Now I see I have started streaming from my back end RTSP. I ran a camera in question all night and no other message followed the Data packets have begun arriving. I assume this means all is good. I will leave the openRTSP running longer to see if I get any messages or if it just disconnects. I am making the assumption that my camera is streaming, because openRTSP does not exit or report streaming has stopped. I do have one question, if the proxy server or openRTSP loses a session from a camera it will reconnect, correct? Thanks, Craig On 11/18/2013 12:48 AM, Ross Finlayson wrote: So I have verified the source device is streaming data. I have connected to it's RTSP stream directly, using gstreamer and vlc. I will connect the openRTSP to the source back-end when it fails and see if it works. No! You should test your back-end stream using "openRTSP" *FIRST*, before using a media player. The reason for this is that media players usually do not give you a clear indication of what is going on. (For example, "VLC" automatically - behind the scenes - requests RTP/RTCP-over-TCP streaming if RTP-over-UDP streaming appears to fail. So you won't know whether or not you need to give the proxy server the "-t" option.) NOTE TO EVERYONE: When you're testing a RTSP stream to check whether it's available, "openRTSP" should be the *FIRST* thing that you try. Only then should you try using a media player. And it makes no sense to talk about "connecting openRTSP (or any other client) to a back-end stream when it fails", because that probably won't tell you anything. You'd be requesting a whole new session. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 18 11:06:27 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Nov 2013 11:06:27 -0800 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: <528A314F.5060109@vivint.com> References: <5289AB6C.6090100@vivint.com> <5289BD04.70704@vivint.com> <528A314F.5060109@vivint.com> Message-ID: <62541A3B-2E34-4450-92AD-AC5D63E7DAF2@live555.com> > After running openRTSP the last thing displayed is Data packets have begun arriving [#####], I did not here any beep. After browsing the source I found that the playCommon.cpp has this message and a \007, which apparently did not cause the beep (no big deal). Now I see I have started streaming from my back end RTSP. I ran a camera in question all night and no other message followed the Data packets have begun arriving. I assume this means all is good. Yes. You should see a (large) file - containing H.264 Elementary Stream video data - sitting in the directory from which you ran "openRTSP". (If you wish, you can rename this - with a ".h264" filename suffix - and VLC should be able to play it.) > I do have one question, if the proxy server or openRTSP loses a session from a camera it will reconnect, correct? The proxy server will; but openRTSP will not (it's just a simple client application, that connects and streams only once). http://www.live555.com/openRTSP Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at stoplift.com Mon Nov 18 14:51:54 2013 From: matt at stoplift.com (Matt Farrow) Date: Mon, 18 Nov 2013 17:51:54 -0500 Subject: [Live-devel] RTP-Info line in PLAY response Message-ID: <2ED328A9368AB0419DD0009540B2A47F8F52F32295@MAILR019.mail.lan> Hi All, I am using the openRTSP code base to obtain frames from a video encoders and store them to disk. I use the MediaSubsession::getNormalPlayTime() quite extensively to calculate and store some timing information with the incoming frames. This process works well. However recently, I have been tasked to work with an encoder that does not provide the "rtptime" field in the "RTP-Info" line of the PLAY response. See below: RTP-Info: url=trackID=1;seq=58643,url=trackID=2;seq=1 This causes the getNormalPlayTime() function to always return 0 since the RTP-Info field was not successfully parsed. This all makes very good sense but I would like to try and use the normal play time functionality so that I can use this encoder. How would you recommend I work around this problem? Can I use the presentation time from the first frame and manually fill in the rtpInfo myself? What would I use for the sequence number? Thanks in advance! Regards, matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 18 19:29:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Nov 2013 19:29:18 -0800 Subject: [Live-devel] RTP-Info line in PLAY response In-Reply-To: <2ED328A9368AB0419DD0009540B2A47F8F52F32295@MAILR019.mail.lan> References: <2ED328A9368AB0419DD0009540B2A47F8F52F32295@MAILR019.mail.lan> Message-ID: > How would you recommend I work around this problem? Why don't you ask the manufacturer of the encoder server to fix it so that it includes the "rtptime" parameter in the "RTP-Info:" header? Without that, you won't be able to use "getNormalPlayTime()". But you may be able to estimate the 'normal play time' by looking at (and subtracting) presentation times. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghav at fossilshale.com Tue Nov 19 02:28:43 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Tue, 19 Nov 2013 15:58:43 +0530 Subject: [Live-devel] Playsip is failing with 482 [LOOP detected] Message-ID: <20131119155843.84424sfjmblhpoij@just60.justhost.com> Hi Ross, Am trying to use playsip whenever am running it am getting error Loop detected error. ./playSip sip:username at iptel.org what will be the issue? Thanks, Raghav. From raghav at fossilshale.com Tue Nov 19 04:57:35 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Tue, 19 Nov 2013 18:27:35 +0530 Subject: [Live-devel] Playsip is failing with 482 [LOOP detected] In-Reply-To: <20131119155843.84424sfjmblhpoij@just60.justhost.com> References: <20131119155843.84424sfjmblhpoij@just60.justhost.com> Message-ID: <20131119182735.16126spvo3neocov@just60.justhost.com> Hi Ross, I forgot to attach log with last message. Here is the Request and Response log. Sending request: INVITE sip:raghav.goud12 at iptel.org SIP/2.0 From: raghav.goud12 ;tag=612715021 Via: SIP/2.0/UDP 192.168.2.232:35728 Max-Forwards: 70 To: sip:raghav.goud12 at iptel.org Contact: sip:raghav.goud12 at 192.168.2.232:35728 Call-ID: 2041292707 at 192.168.2.232 CSeq: 1 INVITE Content-Type: application/sdp User-Agent: playSIP (LIVE555 Streaming Media v2013.10.25) Content-Length: 118 v=0 o=- 2041292707 0 IN IP4 192.168.2.232 s=playSIP session c=IN IP4 192.168.2.232 t=0 0 m=audio 8000 RTP/AVP 0 Received INVITE response: SIP/2.0 482 Loop Detected From: raghav.goud12 ;tag=612715021 Via: SIP/2.0/UDP 192.168.2.232:35728;received=27.34.241.138 To: sip:raghav.goud12 at iptel.org;tag=08EEDDD8-528B2827000D7339-AFDFD700 Call-ID: 2041292707 at 192.168.2.232 CSeq: 1 INVITE Content-Length: 0 Failed to get a SDP description for the URL "sip:raghav.goud12 at iptel.org": (NULL) Thanks, Raghav. Quoting raghav at fossilshale.com: > Hi Ross, > Am trying to use playsip whenever am running it am getting error > Loop detected error. > ./playSip sip:username at iptel.org > > what will be the issue? > Thanks, > Raghav. > From cmatsuura at vivint.com Tue Nov 19 07:42:46 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Tue, 19 Nov 2013 08:42:46 -0700 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: <62541A3B-2E34-4450-92AD-AC5D63E7DAF2@live555.com> References: <5289AB6C.6090100@vivint.com> <5289BD04.70704@vivint.com> <528A314F.5060109@vivint.com> <62541A3B-2E34-4450-92AD-AC5D63E7DAF2@live555.com> Message-ID: <528B86F6.4000806@vivint.com> I've been running for two days with openRTSP on a camera that had problems, openRTSP is still capturing video to the output file and the console last message has not changed. One thing to note is when streaming stops from the proxy of the camera, if I connect to the camera directly it will stream. My test was with gstreamer and not openRTSP to the proxy. Could it be possible the problem is with the proxy session to the camera? I'm no expert on RTSP but trying to learn as much as possible so I can stop asking so many questions. I had to stop the openRTSP as I was running low on disk so I will restart it again to be sure the camera (back-end) continue to work. If there is something else I can run it might be helpful? Do you think using openRTSP connecting to the proxy server would shed any info? Also to note, I did not have to use -t as UDP works fine. Thanks, Craig On 11/18/2013 12:06 PM, Ross Finlayson wrote: After running openRTSP the last thing displayed is Data packets have begun arriving [#####], I did not here any beep. After browsing the source I found that the playCommon.cpp has this message and a \007, which apparently did not cause the beep (no big deal). Now I see I have started streaming from my back end RTSP. I ran a camera in question all night and no other message followed the Data packets have begun arriving. I assume this means all is good. Yes. You should see a (large) file - containing H.264 Elementary Stream video data - sitting in the directory from which you ran "openRTSP". (If you wish, you can rename this - with a ".h264" filename suffix - and VLC should be able to play it.) I do have one question, if the proxy server or openRTSP loses a session from a camera it will reconnect, correct? The proxy server will; but openRTSP will not (it's just a simple client application, that connects and streams only once). http://www.live555.com/openRTSP Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Tue Nov 19 08:10:46 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Tue, 19 Nov 2013 09:10:46 -0700 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: <528B86F6.4000806@vivint.com> References: <5289AB6C.6090100@vivint.com> <5289BD04.70704@vivint.com> <528A314F.5060109@vivint.com> <62541A3B-2E34-4450-92AD-AC5D63E7DAF2@live555.com> <528B86F6.4000806@vivint.com> Message-ID: <528B8D86.7040301@vivint.com> I had a a second system setup at work and when I got into work today I saw the following from the openRTSP. It does appear there was a failure, would this cause a problem with the proxy server? Date: Mon, 18 Nov 2013 12:31:37 GMT Session: 400662;timeout=80 RTP-Info: url=rtsp://192.168.3.217/live.sdp/trackID=1;seq=0;rtptime=0 Range: npt=0- RTCP-Interval: 250 Started playing session Receiving streamed data (signal with "kill -HUP 14502" or "kill -USR1 14502" to terminate)... Data packets have begun arriving [1384803098725] MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 15034 by tes of trailing data will be dropped! FileSink::afterGettingFrame(): The input frame data was too large for our buffer size (100000). 15034 bytes of trailing da ta was dropped! Correct this by increasing the "bufferSize" parameter in the "createNew()" call to at least 115034 Sending request: TEARDOWN rtsp://192.168.3.217/live.sdp/ RTSP/1.0 CSeq: 6 User-Agent: /home/root/openRTSP (LIVE555 Streaming Media v2013.11.15) Session: 400662 Received 45 new bytes of response data. Received a complete TEARDOWN response: RTSP/1.0 200 OK CSeq: 6 Session: 400662 Thanks, Craig On 11/19/2013 08:42 AM, Craig Matsuura wrote: I've been running for two days with openRTSP on a camera that had problems, openRTSP is still capturing video to the output file and the console last message has not changed. One thing to note is when streaming stops from the proxy of the camera, if I connect to the camera directly it will stream. My test was with gstreamer and not openRTSP to the proxy. Could it be possible the problem is with the proxy session to the camera? I'm no expert on RTSP but trying to learn as much as possible so I can stop asking so many questions. I had to stop the openRTSP as I was running low on disk so I will restart it again to be sure the camera (back-end) continue to work. If there is something else I can run it might be helpful? Do you think using openRTSP connecting to the proxy server would shed any info? Also to note, I did not have to use -t as UDP works fine. Thanks, Craig On 11/18/2013 12:06 PM, Ross Finlayson wrote: After running openRTSP the last thing displayed is Data packets have begun arriving [#####], I did not here any beep. After browsing the source I found that the playCommon.cpp has this message and a \007, which apparently did not cause the beep (no big deal). Now I see I have started streaming from my back end RTSP. I ran a camera in question all night and no other message followed the Data packets have begun arriving. I assume this means all is good. Yes. You should see a (large) file - containing H.264 Elementary Stream video data - sitting in the directory from which you ran "openRTSP". (If you wish, you can rename this - with a ".h264" filename suffix - and VLC should be able to play it.) I do have one question, if the proxy server or openRTSP loses a session from a camera it will reconnect, correct? The proxy server will; but openRTSP will not (it's just a simple client application, that connects and streams only once). http://www.live555.com/openRTSP Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 19 10:47:22 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Nov 2013 10:47:22 -0800 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: <528B8D86.7040301@vivint.com> References: <5289AB6C.6090100@vivint.com> <5289BD04.70704@vivint.com> <528A314F.5060109@vivint.com> <62541A3B-2E34-4450-92AD-AC5D63E7DAF2@live555.com> <528B86F6.4000806@vivint.com> <528B8D86.7040301@vivint.com> Message-ID: <9A5316DC-1BB5-43C2-8A47-2A107BC830E8@live555.com> > Started playing session > Receiving streamed data (signal with "kill -HUP 14502" or "kill -USR1 14502" to terminate)... > Data packets have begun arriving [1384803098725] > > > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 15034 by > tes of trailing data will be dropped! > FileSink::afterGettingFrame(): The input frame data was too large for our buffer size (100000). 15034 bytes of trailing da > ta was dropped! Correct this by increasing the "bufferSize" parameter in the "createNew()" call to at least 115034 That's not a 'failure'; that just indicates that "openRTSP" received data (in this case, probably a H.264 'key' frame') that was too large for its buffer. Giving a larger buffer size to "openRTSP" - by adding the "-b 200000" option - would avoid this. See http://www.live555.com/openRTSP Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 19 10:58:11 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Nov 2013 10:58:11 -0800 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: <528B86F6.4000806@vivint.com> References: <5289AB6C.6090100@vivint.com> <5289BD04.70704@vivint.com> <528A314F.5060109@vivint.com> <62541A3B-2E34-4450-92AD-AC5D63E7DAF2@live555.com> <528B86F6.4000806@vivint.com> Message-ID: > I've been running for two days with openRTSP on a camera that had problems, openRTSP is still capturing video to the output file and the console last message has not changed. > > One thing to note is when streaming stops from the proxy of the camera, if I connect to the camera directly it will stream. My test was with gstreamer and not openRTSP to the proxy. > > Could it be possible the problem is with the proxy session to the camera? I'm no expert on RTSP but trying to learn as much as possible so I can stop asking so many questions. > > I had to stop the openRTSP as I was running low on disk so I will restart it again to be sure the camera (back-end) continue to work. > > If there is something else I can run it might be helpful? Do you think using openRTSP connecting to the proxy server would shed any info? Right now I think we're beyond the point where I can continue to provide assistance - on this mailing list - for free. If your management is interested in having me consult with your company to help resolve whatever problems you seem to be having with the software, then please have them contact be via separate email (i.e., not on this mailing list). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Tue Nov 19 11:24:51 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Tue, 19 Nov 2013 12:24:51 -0700 Subject: [Live-devel] Proxy Server Debugging In-Reply-To: References: <5289AB6C.6090100@vivint.com> <5289BD04.70704@vivint.com> <528A314F.5060109@vivint.com> <62541A3B-2E34-4450-92AD-AC5D63E7DAF2@live555.com> <528B86F6.4000806@vivint.com> Message-ID: <528BBB03.8020208@vivint.com> They might. What is your rates? Thanks, Craig On 11/19/2013 11:58 AM, Ross Finlayson wrote: I've been running for two days with openRTSP on a camera that had problems, openRTSP is still capturing video to the output file and the console last message has not changed. One thing to note is when streaming stops from the proxy of the camera, if I connect to the camera directly it will stream. My test was with gstreamer and not openRTSP to the proxy. Could it be possible the problem is with the proxy session to the camera? I'm no expert on RTSP but trying to learn as much as possible so I can stop asking so many questions. I had to stop the openRTSP as I was running low on disk so I will restart it again to be sure the camera (back-end) continue to work. If there is something else I can run it might be helpful? Do you think using openRTSP connecting to the proxy server would shed any info? Right now I think we're beyond the point where I can continue to provide assistance - on this mailing list - for free. If your management is interested in having me consult with your company to help resolve whatever problems you seem to be having with the software, then please have them contact be via separate email (i.e., not on this mailing list). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Tue Nov 19 15:37:22 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Tue, 19 Nov 2013 16:37:22 -0700 Subject: [Live-devel] Hooking into LivenessCommand Message-ID: <528BF632.6060708@vivint.com> I'm looking at using the liveness to indicate to my app if the cameras are online, I was going to sub-class ProxyRTSPClient and override continueAfterLivenessCommand, but it is not virtual. Is there a better way to hook the continueAfterLivenessCommand, so I can determine if the connection to the camera is still live or online state of the cameras I'm connecting too? Thanks, Craig From finlayson at live555.com Tue Nov 19 15:55:58 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Nov 2013 15:55:58 -0800 Subject: [Live-devel] Hooking into LivenessCommand In-Reply-To: <528BF632.6060708@vivint.com> References: <528BF632.6060708@vivint.com> Message-ID: <436BD3F8-2609-4161-8F1C-00A885DEFED4@live555.com> On Nov 19, 2013, at 3:37 PM, Craig Matsuura wrote: > I'm looking at using the liveness to indicate to my app if the cameras > are online, I was going to sub-class ProxyRTSPClient and override > continueAfterLivenessCommand, but it is not virtual. Is there a better > way to hook the continueAfterLivenessCommand, so I can determine if the > connection to the camera is still live or online state of the cameras > I'm connecting too? You don't need to modify any code at all. Just run the "LIVE555 Proxy Server" with the "-V" (verbose output) option. You'll then see quite clearly if/when the RTSP "OPTIONS" command (sent periodically by the proxy to the back-end server) is being replied to. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Tue Nov 19 16:46:43 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Tue, 19 Nov 2013 17:46:43 -0700 Subject: [Live-devel] Hooking into LivenessCommand Message-ID: I want to integrate the capability into my app and not look at logs. My app is a proxy server that I can add and remove camera dynamically. So looking at log messages is not ideal. I did sub class the base environment and override the logging to capture to log else where besides stderr. So it could be done. Are the logs guaranteed to stay the same? Thanks, Craig Sent from my Verizon Wireless 4G LTE DROID Ross Finlayson wrote: On Nov 19, 2013, at 3:37 PM, Craig Matsuura > wrote: I'm looking at using the liveness to indicate to my app if the cameras are online, I was going to sub-class ProxyRTSPClient and override continueAfterLivenessCommand, but it is not virtual. Is there a better way to hook the continueAfterLivenessCommand, so I can determine if the connection to the camera is still live or online state of the cameras I'm connecting too? You don't need to modify any code at all. Just run the "LIVE555 Proxy Server" with the "-V" (verbose output) option. You'll then see quite clearly if/when the RTSP "OPTIONS" command (sent periodically by the proxy to the back-end server) is being replied to. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 19 23:28:48 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Nov 2013 23:28:48 -0800 Subject: [Live-devel] Hooking into LivenessCommand In-Reply-To: References: Message-ID: > Are the logs guaranteed to stay the same? Of course there's no guarantee. But that doesn't really matter, because the code will always remain Open Source. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssingh at neurosoft.in Wed Nov 20 00:19:42 2013 From: ssingh at neurosoft.in (ssingh at neurosoft.in) Date: Wed, 20 Nov 2013 13:49:42 +0530 Subject: [Live-devel] Live555 license info Message-ID: <5ddeec96b85da8d9f84beaca32ad7175@neurosoft.in> Hi, I read that live555 is LGPL licensed but the build for live555 creates static libraries. If I am correct than LGPL dictates that the application links to it dynamically. Is there any plan to change the build type to dynamic for live555 or do I have to create dynamic library myself which would mean I have to distribute the changed codebase for live555. -C From finlayson at live555.com Wed Nov 20 01:28:30 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Nov 2013 01:28:30 -0800 Subject: [Live-devel] Live555 license info In-Reply-To: <5ddeec96b85da8d9f84beaca32ad7175@neurosoft.in> References: <5ddeec96b85da8d9f84beaca32ad7175@neurosoft.in> Message-ID: > I read that live555 is LGPL licensed Yes. > but the build for live555 creates static libraries. Not necessarily. You can create dynamic-linked libraries for Linux by running genMakefiles linux-with-shared-libraries Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eadeli at gmail.com Wed Nov 20 01:33:43 2013 From: eadeli at gmail.com (Ehsan Adeli) Date: Wed, 20 Nov 2013 13:03:43 +0330 Subject: [Live-devel] Splitting files while recording via openRTSP Message-ID: Dear all, I am trying to use the openRTSP test project to record a live RTSP stream. The stream is being played continuously (from a camera) and I want to record the video. In order to be able to manage the recorded files, I want to split the recording and save, for instance, every 5 minutes of the stream in a separate mp4 file. The important thing is that I do not want to stop and start the recoding, because with that I would miss some frames, spending time on closing the connection and reopening. So, I am working on the code. I try to keep the continuous play (-c option) on, and try to redirect stdout to separate files at the beginning of the every step. The problem is that I need to manage the heads and tails of the mp4 files (if I am right). It would be very nice if you could help me with this issue or let me know if there are other ways around, that can be useful for me. Thank you all for your considerations. Regards, Ehsan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbischan at watchtower-security.com Wed Nov 20 07:11:04 2013 From: bbischan at watchtower-security.com (Bob Bischan) Date: Wed, 20 Nov 2013 09:11:04 -0600 Subject: [Live-devel] Splitting files while recording via openRTSP In-Reply-To: References: Message-ID: This would be a great option for the openRTSP client! I have the same issue you described with wanting to avoid gaps between output files. I suppose you could always start another client before the other client terminates to create overlapping recordings, however, that seems more like a work-around than a solution. Not sure if this could be added as an option to openRTSP, but it would be very convenient for the implementation described. Bob On Wed, Nov 20, 2013 at 3:33 AM, Ehsan Adeli wrote: > Dear all, > > I am trying to use the openRTSP test project to record a live RTSP stream. > The stream is being played continuously (from a camera) and I want to > record the video. In order to be able to manage the recorded files, I want > to split the recording and save, for instance, every 5 minutes of the > stream in a separate mp4 file. The important thing is that I do not want to > stop and start the recoding, because with that I would miss some frames, > spending time on closing the connection and reopening. So, I am working on > the code. I try to keep the continuous play (-c option) on, and try to > redirect stdout to separate files at the beginning of the every step. The > problem is that I need to manage the heads and tails of the mp4 files (if I > am right). > > It would be very nice if you could help me with this issue or let me know > if there are other ways around, that can be useful for me. Thank you all > for your considerations. > > Regards, > Ehsan > > > > _______________________________________________ > 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 cmatsuura at vivint.com Wed Nov 20 08:15:34 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Wed, 20 Nov 2013 09:15:34 -0700 Subject: [Live-devel] Is there a better command to use other than OPTION for keep-alive? Message-ID: <528CE026.2080307@vivint.com> I see that the OPTION command is used for keeping a stream alive. I there a better command that can be used that can also indicate the stream is still running? If an OPTION is send on or outside the timeout of the camera the stream stops but what is the indication that it has stopped? I see that the ProxyServerMediaSession.cpp method ProxyRTSPClient::scheduleLivenessCommand has the following comment: // Choose a random time from [delayMax/2,delayMax) seconds: If delayMax is choosen, and a camera reports timeout=XX, should XX ever be used? With latency in some systems sending an OPTION command, or very slow wifi you could get outside this window I believe? I think a delayMax should never be used, but something less than the max? Thanks, Craig From umar at janteq.com Wed Nov 20 11:37:57 2013 From: umar at janteq.com (Umar Qureshey) Date: Wed, 20 Nov 2013 19:37:57 +0000 Subject: [Live-devel] Inserting SPS/PPS repeatedly in TS file Message-ID: Hi, I am streaming from H.264 Elementary Stream (ES) over RTP from an IP camera and creating a Transport Stream (TS) which I send over UDP. I have modified "testH264VideoToTransportStream" to take input from 'stdin' and send to a UDP client (H.264 decoder) by replacing FileSink with BasicUDPSink. Here is my command line: ./openRTSP -v rtsp://192.168.1.214/axis-media/media.amp?streamprofile=Quality | ./testH264VideoToTransportStreamUDP The issue I am encountering is that if, during the process of streaming, the client loses connection and then reconnects, it cannot decode the stream because it cannot see SPS/PPS. I analyzed a saved TS file and I noticed that the SPS/PPS is only sent with the first IDR frame and then never again. So my question is what would be a way to have SPS/PPS NAL units repeated in the TS stream by the MPEG2TransportStreamFromESSource filter so that a UDP client (decoder) can resume decoding after intermittently disconnecting and reconnecting? Thanks. From finlayson at live555.com Wed Nov 20 12:37:56 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Nov 2013 12:37:56 -0800 Subject: [Live-devel] Splitting files while recording via openRTSP In-Reply-To: References: Message-ID: > This would be a great option for the openRTSP client! I agree - it would be a great option for "openRTSP": http://live555.com/funded-projects/live555_openrtsp_interval_files.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 20 12:50:58 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Nov 2013 12:50:58 -0800 Subject: [Live-devel] Is there a better command to use other than OPTION for keep-alive? In-Reply-To: <528CE026.2080307@vivint.com> References: <528CE026.2080307@vivint.com> Message-ID: > I see that the OPTION command is used for keeping a stream alive. I > there a better command that can be used that can also indicate the > stream is still running? Not really. Every server should support "OPTIONS". ("GET_PARAMETER" could also be used, but some servers don't support this.) > // Choose a random time from [delayMax/2,delayMax) seconds: > > If delayMax is choosen, and a camera reports timeout=XX, should XX ever > be used? It *is* used - to compute "delayMax". (Note the call to "sessionTimeoutParameter()", which returns this value.) > I think a delayMax should never be used, but something less than the max? The code does this - that's why the comment in the code says "[delayMax/2,delayMax)", rather than "[delayMax/2,delayMax]". In any case, a standards-compliant server (e.g., network camera) should also be using RTCP "RR" packets - sent by the proxy server - to indicate liveness. It should not be relying just upon the periodic "OPTIONS" commands. ----------------------- A reminder to everyone, once again: If anyone is having a problem with one particular third-party server or client, then I need to hear *directly* from the manufacturer of that third-party server or client. (Via the "live-devel" mailing list is OK.) I will not spend any time debugging (or attempting to 'work around') a buggy third-party server or client solely via an intermediary. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 20 13:00:21 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Nov 2013 13:00:21 -0800 Subject: [Live-devel] Inserting SPS/PPS repeatedly in TS file In-Reply-To: References: Message-ID: > ./openRTSP -v rtsp://192.168.1.214/axis-media/media.amp?streamprofile=Quality | ./testH264VideoToTransportStreamUDP > > The issue I am encountering is that if, during the process of streaming, the client loses connection and then reconnects, it cannot decode the stream because it cannot see SPS/PPS. I analyzed a saved TS file and I noticed that the SPS/PPS is only sent with the first IDR frame and then never again. > > So my question is what would be a way to have SPS/PPS NAL units repeated in the TS stream by the MPEG2TransportStreamFromESSource filter so that a UDP client (decoder) can resume decoding after intermittently disconnecting and reconnecting? I suggest looking at how "openRTSP" outputs H.264 video data to a file. In particular: - See "testProgs/playCommon.cpp", line 830, and note the call to "subsession->fmtp_spropparametersets()". - See also the implementation of the "H264VideoFileSink" class ("liveMedia/H264VideoFileSink.cpp", line 66), and note how it parses the 'sprop-parameter-string' into SPS/PPS NAL-units, by calling "parseSPropParameterSets()". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From umar at janteq.com Wed Nov 20 17:27:18 2013 From: umar at janteq.com (Umar Qureshey) Date: Thu, 21 Nov 2013 01:27:18 +0000 Subject: [Live-devel] Inserting SPS/PPS repeatedly in TS file In-Reply-To: References: Message-ID: Thanks, that is very helpful. From cmatsuura at vivint.com Wed Nov 20 16:38:52 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Wed, 20 Nov 2013 17:38:52 -0700 Subject: [Live-devel] continueAfterOPTIONS late Message-ID: <528D561C.3050800@vivint.com> If the continueAfterOPTIONS command is late (longer than the liveness timeout) I assume the camera would time out and shutdown the session? I don't see anywhere in continueAfterLivenessCommand that it handles this? Thanks, Craig From finlayson at live555.com Wed Nov 20 20:59:11 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Nov 2013 20:59:11 -0800 Subject: [Live-devel] continueAfterOPTIONS late In-Reply-To: <528D561C.3050800@vivint.com> References: <528D561C.3050800@vivint.com> Message-ID: <29D137D6-BAA9-4826-B9A4-84D49F8424BD@live555.com> > If the continueAfterOPTIONS command is late (longer than the liveness > timeout) I assume the camera would time out and shutdown the session? I > don't see anywhere in continueAfterLivenessCommand that it handles this? Phew... 1/ The interval between two successive "OPTIONS" commands will almost never exceed the "timeout=" parameter that the server reported. (A future release of the software will ensure that it *never* exceeds this - because the interval will be randomly chosen from "[delayMax/2,delayMax-1)" instead of the current "[delayMax/2,delayMax)".) 2/ In any case, this shouldn't matter, because - as I've said AD NAUSEAM - the proxy server will send RTCP "RR" packets far more frequently than this, and standards-compliant (i.e., correctly implemented) server will use these as an indication that the proxy server is still alive. 3/ Should the camera "time out the shutdown the session" - for any reason - then the subsequent "OPTIONS" command from the proxy server will fail, and the proxy server will then reopen the connection. That's the PRIMARY PURPOSE of the periodic "OPTIONS" commands: To check whether the server still thinks that the session is alive. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Wed Nov 20 21:24:09 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Wed, 20 Nov 2013 22:24:09 -0700 Subject: [Live-devel] continueAfterOPTIONS late In-Reply-To: <29D137D6-BAA9-4826-B9A4-84D49F8424BD@live555.com> References: <528D561C.3050800@vivint.com> <29D137D6-BAA9-4826-B9A4-84D49F8424BD@live555.com> Message-ID: <528D98F9.5080403@vivint.com> On 11/20/2013 08:59 PM, Ross Finlayson wrote: If the continueAfterOPTIONS command is late (longer than the liveness timeout) I assume the camera would time out and shutdown the session? I don't see anywhere in continueAfterLivenessCommand that it handles this? Phew... 1/ The interval between two successive "OPTIONS" commands will almost never exceed the "timeout=" parameter that the server reported. (A future release of the software will ensure that it *never* exceeds this - because the interval will be randomly chosen from "[delayMax/2,delayMax-1)" instead of the current "[delayMax/2,delayMax)".) I made a similar change for the delayMax, but instead subtracted 10, because I would see latency when I was logging OPTION commands. I have a extremely busy WIFI network for testing. Thanks for that change as it is along the lines I was think and confirms what I was seeing. 2/ In any case, this shouldn't matter, because - as I've said AD NAUSEAM - the proxy server will send RTCP "RR" packets far more frequently than this, and standards-compliant (i.e., correctly implemented) server will use these as an indication that the proxy server is still alive. 3/ Should the camera "time out the shutdown the session" - for any reason - then the subsequent "OPTIONS" command from the proxy server will fail, and the proxy server will then reopen the connection. That's the PRIMARY PURPOSE of the periodic "OPTIONS" commands: To check whether the server still thinks that the session is alive. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.bekker at vdgsecurity.com Thu Nov 21 07:54:41 2013 From: w.bekker at vdgsecurity.com (Wim Bekker) Date: Thu, 21 Nov 2013 16:54:41 +0100 Subject: [Live-devel] What is the preferred way of terminating an RTSP server connection Message-ID: What is the preferred way of terminating an RTSP server connection? My RTSP server has several connections (clientSessions) and I want to drop some of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Nov 21 08:15:42 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 21 Nov 2013 08:15:42 -0800 Subject: [Live-devel] What is the preferred way of terminating an RTSP server connection In-Reply-To: References: Message-ID: > What is the preferred way of terminating an RTSP server connection? > > My RTSP server has several connections (clientSessions) and I want to drop some of them. There's no easy way to terminate (from the server) just 'some' connections. (What criterion would you use to decide which connections you want to terminate??) However, you can terminate *all* connections for a given stream by calling RTSPServer::closeAllClientSessionsForServerMediaSession() Plus, of course, if you delete the entire "RTSPServer" object - by calling "Medium::close(pointer-to-your-RTSPServer-object);" - then *all* connections to the server (and all resources used by the server) will be reclaimed. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishnaks at iwavesystems.com Thu Nov 21 21:13:30 2013 From: krishnaks at iwavesystems.com (Krishna) Date: Fri, 22 Nov 2013 10:43:30 +0530 Subject: [Live-devel] Audio/Video Sink - Video stops in between Message-ID: <7CAD67B30147408586EF02CCBD7CFAFD@IWAVE> Hi Ross, I confirmed that Video stop is not because of frame loss. I checked in VLC statistics. Is that can be bandwidth problem? Estimated bandwidth for audio is 64 kbps(derived from (bitsPerSecond + 500)/1000) Estimated bandwidth for video is 500 kbps Thanks in advance, Krishna From: Krishna Sent: Monday, November 18, 2013 1:22 PM To: LIVE555 Streaming Media - development & use Subject: Audio/Video Sink - Video stops in between HI Ross, I have a problem in Audio/Video sink. Video comes from camera and encoding to H.264 and audio comes directly from microphone (PCM 16-bit LE, Sampling frequency is 8k, mono(1 channel)). We are able to get Video, Audio sink with the minimal delay. Now the problem is Sometimes Video stops for a while (for some 500ms; I guess to make Sink) which I need to avoid. How I can avoid that? Regards, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.bekker at vdgsecurity.com Fri Nov 22 03:30:41 2013 From: w.bekker at vdgsecurity.com (Wim Bekker) Date: Fri, 22 Nov 2013 12:30:41 +0100 Subject: [Live-devel] What is the preferred way of terminating an RTSP server connection In-Reply-To: References: Message-ID: > > What is the preferred way of terminating an RTSP server connection? > > My RTSP server has several connections (clientSessions) and I want to drop > some of them. > > > There's no easy way to terminate (from the server) just 'some' > connections. (What criterion would you use to decide which connections you > want to terminate??) > > However, you can terminate *all* connections for a given stream by calling > RTSPServer::closeAllClientSessionsForServerMediaSession() > > Plus, of course, if you delete the entire "RTSPServer" object - by calling > "Medium::close(pointer-to-your-RTSPServer-object);" - then *all* > connections to the server (and all resources used by the server) will be > reclaimed. > Ok thanks. What about stopGettingFrames in FramedSource? I'll try that one because I have easy access to that object. Is there any documentation I can read about how this works, how objects are linked to each other, how flow goes? A reference manual would also be great. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 22 07:28:38 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Nov 2013 07:28:38 -0800 Subject: [Live-devel] What is the preferred way of terminating an RTSP server connection In-Reply-To: References: Message-ID: > There's no easy way to terminate (from the server) just 'some' connections. (What criterion would you use to decide which connections you want to terminate??) > > However, you can terminate *all* connections for a given stream by calling > RTSPServer::closeAllClientSessionsForServerMediaSession() > > Plus, of course, if you delete the entire "RTSPServer" object - by calling "Medium::close(pointer-to-your-RTSPServer-object);" - then *all* connections to the server (and all resources used by the server) will be reclaimed. > > Ok thanks. What about stopGettingFrames in FramedSource? I'll try that one because I have easy access to that object. (I assume that you're referring to the data source object for your stream?) Calling "stopGettingFrames()" on that object will stop data (and thus RTP packets) from flowing, but it won't tear down any connections to clients. You haven't said anything about *which* connections you want to terminate, and why. If you're worried only about terminating connections to 'dead' clients (i.e., clients that just disappear, without sending a RTSP "TEARDOWN"), then you don't need to worry. The server will automatically close (and reclaim resources for) those connections after a period of time (by default, 65 seconds). > Is there any documentation I can read about how this works, how objects are linked to each other, how flow goes? http://www.live555.com/liveMedia/faq.html#doc > A reference manual would also be great. Yes, that would be great. But this is not a charity :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From umar at janteq.com Fri Nov 22 16:43:16 2013 From: umar at janteq.com (Umar Qureshey) Date: Sat, 23 Nov 2013 00:43:16 +0000 Subject: [Live-devel] Sony SNC-RZ50N RTSP stream stopping Message-ID: Hello, I am using openRTSP to receive a H.264 stream from a Sony SNC-RZ50N camera. All goes fine but around the time I get 8MB of data the video disappears. This is because the camera stops sending it (I confirmed through Wireshark). However the RTCP packets seem to be still going. I use VLC to stream from the same camera and it seems to stream on forever. I do realize VLC uses Live555 so unsure why it behaves differently. I enabled DEBUG in the live555 code and got a trace which I am pasting below. Basically after the last "validated entire RTCP packet" is printed, the video just disappears. [lab at Fedora-17-Lab live555-pc-testProgs]$ ./openRTSP rtsp://192.168.17.200/media/video0 Opening connection to 192.168.17.200, port 554... ...remote connection opened Sending request: OPTIONS rtsp://192.168.17.200/media/video0 RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.11.10) Received 119 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Public: DESCRIBE, SETUP, PLAY, TEARDOWN, OPTIONS, GET_PARAMETER VersionSupport: IPTV/1.0 Sending request: DESCRIBE rtsp://192.168.17.200/media/video0 RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.11.10) Accept: application/sdp Received 124 new bytes of response data. Have received 124 total bytes of a DESCRIBE RTSP response; awaiting 393 bytes more. Received 393 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Content-Base: rtsp://192.168.17.200/media/ Content-type: application/sdp Content-length: 393 v=0 o=- 1385167236 1385167236 IN IP4 192.168.17.200 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 t=0 0 a=range:npt=0.000000- m=video 0 RTP/AVP 105 a=rtpmap:105 H264/90000 a=control:trackID=0 a=framerate:15.0 a=fmtp:105 packetization-mode=1; profile-level-id=428016; sprop-parameter-sets=Z0KAHhhWgLA9kA==,aAWDDgO8gA== m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=control:trackID=1 Opened URL "rtsp://192.168.17.200/media/video0", returning a SDP description: v=0 o=- 1385167236 1385167236 IN IP4 192.168.17.200 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 t=0 0 a=range:npt=0.000000- m=video 0 RTP/AVP 105 a=rtpmap:105 H264/90000 a=control:trackID=0 a=framerate:15.0 a=fmtp:105 packetization-mode=1; profile-level-id=428016; sprop-parameter-sets=Z0KAHhhWgLA9kA==,aAWDDgO8gA== m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=control:trackID=1 RTCPInstance[0x2619460]::RTCPInstance() schedule(1.131038->1385163166.332455) Created receiver for "video/H264" subsession (client ports 33650-33651) RTCPInstance[0x261a250]::RTCPInstance() schedule(2.643464->1385163167.844932) Created receiver for "audio/PCMU" subsession (client ports 42242-42243) Sending request: SETUP rtsp://192.168.17.200/media/trackID=0 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.11.10) Transport: RTP/AVP;unicast;client_port=33650-33651 Received 188 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Session: 1385167236;timeout=30 Transport: RTP/AVP;unicast;client_port=33650-33651;server_port=50006-50007;ssrc=8c34299c;mode="PLAY" VersionSupport: IPTV/1.0 Setup "video/H264" subsession (client ports 33650-33651) Sending request: SETUP rtsp://192.168.17.200/media/trackID=1 RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.11.10) Transport: RTP/AVP;unicast;client_port=42242-42243 Session: 1385167236 Received 188 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Session: 1385167236;timeout=30 Transport: RTP/AVP;unicast;client_port=42242-42243;server_port=50008-50009;ssrc=927bde2a;mode="PLAY" VersionSupport: IPTV/1.0 Setup "audio/PCMU" subsession (client ports 42242-42243) Created output file: "video-H264-1" Created output file: "audio-PCMU-2" Sending request: PLAY rtsp://192.168.17.200/media/ RTSP/1.0 CSeq: 6 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.11.10) Session: 1385167236 Range: npt=0.000- Received 66 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Session: 1385167236 Range: npt=now- Started playing session Receiving streamed data (signal with "kill -HUP 1215" or "kill -USR1 1215" to terminate)... schedule(0.431897->1385163166.764424) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a681d 5edce39b e1a05988 0002ce22 0e3cdab5 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a681d 6e363b25 45b3c4fa 00006772 00c1f5c0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet schedule(0.336735->1385163167.101247) schedule(1.064203->1385163168.165535) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a681e 3fc51548 45b3dfde 00006780 00c21000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a681e 549f9485 e1a1adb7 0002ce91 0e3f1195 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a ffffffff 000169eb 00000014 681e3fc5 000083bb 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(1.049650->1385163168.894835) sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c ffffffff 0001cb75 00000638 681e549f 0000c0f3 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(1.252704->1385163169.418505) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a681f 3129ed39 45b3fec1 0000678f 00c22c20 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a681f 5ef544bb e1a3195d 0002cf09 0e417840 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet schedule(5.070152->1385163173.965058) schedule(3.806920->1385163173.225494) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6820 56cc3e31 45b42479 000067a3 00c251a0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6820 836544fe e1a4a833 0002cf8b 0e4413cd SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6821 6ddda059 e1a5f0a5 0002cff6 0e463e7b SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6821 6e2a1b5c 45b44830 000067b5 00c27360 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6822 85968512 e1a75c4d 0002d06f 0e48a4b1 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6822 9d02363b 45b46f03 000067c8 00c29700 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6823 1e9057d1 45b47fac 000067d1 00c2a7e0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6823 b308893b e1a90298 0002d0fa 0e4b69b8 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6823 f8766c6d 45b49b95 000067df 00c2c220 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001cdc7 000005de 6823b308 000071e2 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.632167->1385163175.857914) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6824 baaa1943 e1aa6e3d 0002d173 0e4dd058 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016a51 00000019 6823f876 0000e9c9 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.639373->1385163176.604692) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6824 e63b46fd 45b4ba07 000067ef 00c2e020 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6825 706bf013 45b4cbd2 000067f8 00c2f100 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6825 995df655 e1ab9f3b 0002d1d9 0e4fd6dd SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6826 611bc558 45b4ea88 00006807 00c30d20 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6826 bfdf090f e1ad4586 0002d264 0e529a50 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet schedule(2.633430->1385163178.501961) schedule(3.041214->1385163179.645981) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6827 99c347e8 45b512a8 0000681c 00c33480 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6827 d1bff045 e1aeb12b 0002d2dd 0e550076 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6828 a8c9a77e 45b5356a 0000682d 00c35460 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6828 f589374b e1b04bbb 0002d368 0e57c45e SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001d028 000005fa 6828f589 00007625 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.510792->1385163182.013000) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6829 a8cd7492 45b55644 0000683e 00c37440 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a682a 1c6833c6 45b56508 00006845 00c38160 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a682a 262b4959 e1b1f207 0002d3f2 0e5a88bc SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016ab0 0000001a 682a1c68 00007424 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.909271->1385163185.555502) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a682a ffcd67fd e1b30b90 0002d44c 0e5c5def SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a682b 0f21a2e7 45b58426 00006855 00c39f60 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a682c 2de4a383 45b5a8dd 00006868 00c3c300 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a682c 360242d0 e1b4b1dd 0002d4d6 0e5f227f SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a682c e92146a1 45b5c0da 00006874 00c3d980 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001d1be 0000078d 682c3602 0000b87b 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 reap: checking SSRC 0x8c34299c: 4 (threshold 0) schedule(4.893515->1385163186.906771) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a682c f589efd8 e1b5cb64 0002d534 0e60fb2b SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a682d dbf96180 45b5dfff 00006884 00c3f780 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a682e 2235935f e1b74e80 0002d5b5 0e63933d SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a682e a1113836 45b5f955 00006891 00c40fe0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a682f 381e68a0 e1b8dd55 0002d637 0e662a0e SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a682f abb12902 45b61b7c 000068a2 00c42fc0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6830 662d72ff e1ba83a1 0002d6c1 0e68ef78 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016b13 00000018 682fabb1 0000cdae 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 reap: checking SSRC 0x927bde2a: 4 (threshold 0) schedule(3.186870->1385163188.742618) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6830 d4bdec5f 45b64174 000068b5 00c45360 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6831 96cefed6 e1bc29ec 0002d74c 0e6bb2bf SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet schedule(0.511963->1385163187.418787) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6831 fd3a2df9 45b66785 000068c9 00c478e0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001d430 000005af 683196ce 0000bf90 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.518782->1385163190.937857) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6832 c0e79aae e1bdad09 0002d7ce 0e6e47e2 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6833 0d1efb6d 45b68a60 000068da 00c498c0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet schedule(2.192525->1385163190.935220) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6833 d4c2d6a9 e1bf3023 0002d850 0e70dda6 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6833 f069b5a6 45b6a774 000068e9 00c4b4e0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6834 9ca686e7 e1c03237 0002d8a1 0e72877f SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6835 0f2acfb7 45b6cc51 000068fc 00c4d880 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6835 425edd05 e1c13447 0002d8f6 0e7433c6 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6835 d047b246 45b6e503 00006908 00c4ef00 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet schedule(0.230621->1385163191.165929) schedule(0.360398->1385163191.298325) sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016b70 00000019 6835d047 00004557 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(4.740894->1385163195.907085) schedule(1.073879->1385163192.372281) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6836 6e4723aa e1c2b763 0002d978 0e76cb17 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6836 9e7f8012 45b6ff6d 00006916 00c50940 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6837 1c59b802 e1c3b974 0002d9c9 0e7872d2 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001d672 000007fe 68371c59 00002e17 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.512931->1385163196.885462) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6837 59c8c932 45b7176a 00006922 00c51fc0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6837 f82dbe7f 45b72bc0 0000692c 00c53280 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6838 0f2324c8 e1c501e8 0002da39 0e7aabc5 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6838 df0025bf 45b74957 0000693b 00c54ea0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6839 0f21e603 e1c65618 0002daa9 0e7ce4fb SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6839 e420f6f0 e1c78715 0002db10 0e7eeeb3 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a683a 0cfc71d6 45b77013 0000694f 00c57420 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet schedule(0.705011->1385163196.699611) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a683b 09feeb2d 45b7908f 00006960 00c59400 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a683b 0cffb8b2 e1c915ec 0002db92 0e8186f2 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016bcc 0000004d 683b09fe 00009440 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.662009->1385163202.361882) schedule(1.474104->1385163198.359641) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a683c 0f1eafee e1ca8190 0002dc0b 0e83eec3 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a683c 42f1348b 45b7b8a1 00006974 00c5b980 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a683c e8ccdd93 e1cbb28d 0002dc6e 0e85f295 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a683c ffc610f0 45b7d0d0 00006980 00c5d000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001d929 00000807 683ce8cc 00005e68 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.565660->1385163202.925567) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a683e 0c913a4f e1cd4163 0002dcf0 0e888765 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a683e 1bf23cc8 45b7f535 00006993 00c5f3a0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a683f 0a096787 e1ce89d9 0002dd60 0e8abd8f SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a683f 0daed56b 45b81433 000069a2 00c60fc0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a683f c25cc426 e1cf8030 0002ddb5 0e8c694f SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a683f e1144cbe 45b82f3e 000069b0 00c62a00 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6840 b3994e1a 45b84a54 000069be 00c64440 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6840 e1b317ef e1d10f07 0002de36 0e8efeeb SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016c2b 00000028 6840b399 0000942b 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(4.727299->1385163207.089432) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6841 d778cc9a 45b86fbd 000069d1 00c667e0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet schedule(1.461513->1385163204.387118) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6842 1c6c332f e1d2ccc7 0002dec9 0e91f239 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6843 0f28b6d8 45b897a8 000069e5 00c68d60 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6843 2de16d6d e1d4386d 0002df43 0e9461c0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001dbe7 00000694 68432de1 00002058 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.847450->1385163208.234830) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6844 006e7e62 e1d551f6 0002df9c 0e962db2 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6844 0c96787c 45b8b82d 000069f6 00c6ad40 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6844 cf9f01b8 e1d682f2 0002e002 0e9835e8 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6845 2de9d0e9 45b8dd37 00006a09 00c6d0e0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6845 63fc115d e1d74a5d 0002e041 0e997e3e SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet schedule(0.824462->1385163207.913970) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6846 5f927d45 45b9044e 00006a1c 00c6f480 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6846 663e6c4c e1d8b602 0002e0ba 0e9be5bb SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016c87 00000025 68465f92 00007585 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.306345->1385163213.220584) schedule(0.930420->1385163209.165328) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6847 7b57e670 e1da21a8 0002e133 0e9e4c9a SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6847 99719f7f 45b92c99 00006a31 00c71be0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001de12 000005ca 68477b57 00009a18 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 reap: checking SSRC 0x8c34299c: 9 (threshold 5) schedule(5.414129->1385163214.579733) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6848 a39e3864 e1dbc7f2 0002e1be 0ea11171 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6848 baa9930b 45b951c2 00006a44 00c73f80 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6849 a8bc7b45 e1dd3398 0002e237 0ea377ca SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6849 add5b24e 45b970f0 00006a54 00c75d80 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a684a b82949a5 e1de9f3d 0002e2af 0ea5dda3 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a684a c4e77920 45b9949d 00006a66 00c77f40 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a684b 7078c868 e1dfa14f 0002e300 0ea78459 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a684b b69c560c 45b9b39b 00006a75 00c79b60 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016ce0 00000018 684bb69c 00006cf5 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 reap: checking SSRC 0x927bde2a: 9 (threshold 5) schedule(4.380549->1385163217.601387) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a684c 6eeea63b 45b9cb28 00006a81 00c7b1e0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a684c a8c8de2a e1e1479b 0002e38a 0eaa49a5 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a684d 4a650614 e1e2267c 0002e3d6 0eabc5e5 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001e084 000006f5 684d4a65 0000351e 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.764924->1385163217.344912) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a684d 8f3d3a1d 45b9f035 00006a94 00c7d580 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a684e 0d0f733a e1e33449 0002e434 0eada14c SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a684e 9e8fc0d2 45ba12ef 00006aa6 00c7f740 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a684f 1e8ec52a e1e4aba9 0002e4ae 0eb010ec SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a684f 91b4dceb 45ba321d 00006ab6 00c81540 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6850 32f954eb e1e62ec3 0002e52b 0eb29a6b SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet schedule(0.859661->1385163218.204649) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6850 7b55de58 45ba501e 00006ac5 00c83160 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016d29 00000031 68507b55 000009b6 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(6.092499->1385163223.694133) sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001e225 00000696 685032f9 0000ec85 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(5.739244->1385163223.944144) [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6851 6931337e e1e7d510 0002e5b6 0eb5608b SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6851 b6047d3d 45ba7869 00006ad9 00c856e0 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6852 59663843 e1e9293e 0002e625 0eb79830 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6852 e62bae03 45ba9f66 00006aed 00c87c60 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6853 4d3f1843 e1ea5a3f 0002e68c 0eb9a123 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6853 eee21101 45bac151 00006afe 00c89c40 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6854 2c6b9c30 e1eb8b3d 0002e6f3 0ebbaa33 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6854 bd413122 45badbbe 00006b0c 00c8b680 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6855 4047c30d e1ed0e57 0002e775 0ebe3fff SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6855 e6333764 45bb01c6 00006b1f 00c8da20 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6856 7ab54e2b e1eecc18 0002e809 0ec13383 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016d8e 00000020 6855e633 0000b695 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.767804->1385163229.462188) sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001e4c0 00000625 68567ab5 00006212 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.408136->1385163228.352526) [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6856 e3a01eee 45bb224e 00006b30 00c8fa00 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6857 8a132b55 e1f04378 0002e882 0ec39cb9 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet [0x261a250]saw incoming RTCP packet (from address 192.168.17.200, port 50009) 80c80006 927bde2a d63a6857 d55b8993 45bb414b 00006b3f 00c91620 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x927bde2a validated entire RTCP packet [0x2619460]saw incoming RTCP packet (from address 192.168.17.200, port 50007) 80c80006 8c34299c d63a6858 9966be7a e1f1af1d 0002e8f7 0ec5fe63 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c34299c validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 2d1697ee 8c34299c 00ffffff 0001e5a9 00000575 68589966 0002abec 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.913792->1385163232.266570) sending REPORT sending RTCP packet 81c90007 9f0259cf 927bde2a 00ffffff 00016db3 00000019 6857d55b 00048c0a 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.630649->1385163233.093092) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 reap: checking SSRC 0x8c34299c: 13 (threshold 10) schedule(4.530446->1385163236.797224) schedule(2.513689->1385163235.606856) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.101690->1385163238.708766) schedule(1.485106->1385163238.282407) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.897257->1385163243.179880) schedule(2.309648->1385163241.018488) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 reap: checking SSRC 0x927bde2a: 12 (threshold 10) schedule(4.047553->1385163245.066267) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.280583->1385163246.460683) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.496858->1385163250.563333) schedule(2.328573->1385163248.789335) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.105750->1385163250.895298) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.558691->1385163256.122227) schedule(4.040528->1385163254.935904) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(5.141878->1385163260.078009) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.716520->1385163259.839033) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(4.670989->1385163264.510226) schedule(0.647349->1385163260.725437) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 reap: checking SSRC 0x8c34299c: 13 (threshold 15) reap: removing SSRC 0x8c34299c schedule(5.054357->1385163265.780020) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 reap: checking SSRC 0x927bde2a: 12 (threshold 15) reap: removing SSRC 0x927bde2a schedule(2.972959->1385163267.483401) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.252295->1385163269.032520) schedule(1.938449->1385163269.421926) schedule(1.226110->1385163270.258705) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.578911->1385163273.001055) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.367167->1385163272.626087) schedule(1.283084->1385163273.909254) schedule(1.636277->1385163274.637407) schedule(0.698121->1385163274.607472) schedule(0.530333->1385163275.137897) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.689322->1385163278.326955) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.011608->1385163279.149723) schedule(0.053730->1385163278.380762) schedule(1.614820->1385163279.995671) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.733398->1385163282.883327) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.400000->1385163282.395884) schedule(1.596132->1385163283.992096) schedule(1.237809->1385163284.121224) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.511109->1385163286.503423) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.098377->1385163287.219824) schedule(3.002348->1385163289.505848) schedule(2.718038->1385163289.937940) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.786168->1385163292.292238) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.774804->1385163292.712975) schedule(2.426453->1385163294.718775) schedule(1.197700->1385163293.910758) schedule(0.329093->1385163294.239944) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.287816->1385163298.527977) schedule(0.687372->1385163295.406231) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.480274->1385163297.886724) schedule(2.142703->1385163300.029503) schedule(1.464581->1385163299.992636) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.799086->1385163302.791937) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.808844->1385163305.838565) schedule(3.306020->1385163306.098033) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.386150->1385163309.224918) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(5.318307->1385163311.416558) schedule(1.944188->1385163311.169184) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.032533->1385163314.201931) schedule(0.471200->1385163311.887836) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.078952->1385163315.967013) schedule(2.114429->1385163316.316433) schedule(0.204946->1385163316.172036) schedule(1.762349->1385163317.934474) schedule(0.734143->1385163317.050664) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.665141->1385163319.716022) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.961239->1385163320.895931) schedule(2.249762->1385163321.965857) schedule(2.200889->1385163323.096896) schedule(0.282046->1385163322.247991) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(4.445704->1385163326.693923) schedule(0.463148->1385163323.560133) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.042094->1385163327.602439) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.873163->1385163330.567272) schedule(1.555969->1385163329.158485) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.822253->1385163332.980954) schedule(0.539057->1385163331.106406) schedule(0.161583->1385163331.268078) schedule(0.452063->1385163331.720227) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.748297->1385163335.468709) schedule(1.222855->1385163334.203885) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.381783->1385163337.585860) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.477970->1385163337.946886) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(5.744704->1385163343.330783) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.097900->1385163340.044988) schedule(2.635396->1385163342.680458) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(4.983830->1385163347.664517) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(5.844527->1385163349.175525) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(4.683686->1385163352.348412) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.279567->1385163351.455298) schedule(1.873395->1385163353.328770) schedule(0.737818->1385163353.086304) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.688105->1385163358.774639) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.711755->1385163357.040745) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.908959->1385163361.949910) schedule(0.383932->1385163359.158646) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(3.778990->1385163362.937854) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.886007->1385163364.836132) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.993677->1385163368.931745) schedule(1.329766->1385163366.165976) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(2.315565->1385163368.481767) schedule(2.220989->1385163370.702833) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(2.631912->1385163371.563861) schedule(0.045866->1385163370.748787) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(3.561472->1385163374.310486) schedule(0.778326->1385163372.342269) schedule(2.475007->1385163374.817378) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(5.348346->1385163379.659035) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(5.545494->1385163380.363086) schedule(0.227550->1385163379.886661) sending REPORT sending RTCP packet 80c90001 2d1697ee 81ca0005 2d1697ee 010d4665 646f7261 2d31372d 4c616200 schedule(4.810976->1385163384.697868) sending REPORT sending RTCP packet 80c90001 9f0259cf 81ca0005 9f0259cf 010d4665 646f7261 2d31372d 4c616200 schedule(6.046158->1385163386.409448) Got shutdown signal Sending request: TEARDOWN rtsp://192.168.17.200/media/ RTSP/1.0 CSeq: 7 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.11.10) Session: 1385167236 RTCPInstance[0x2619460]::~RTCPInstance() sending BYE sending RTCP packet 80c90001 2d1697ee 81cb0001 2d1697ee RTCPInstance[0x261a250]::~RTCPInstance() sending BYE sending RTCP packet 80c90001 9f0259cf 81cb0001 9f0259cf From finlayson at live555.com Fri Nov 22 18:47:27 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Nov 2013 18:47:27 -0800 Subject: [Live-devel] Sony SNC-RZ50N RTSP stream stopping In-Reply-To: References: Message-ID: > I am using openRTSP to receive a H.264 stream from a Sony SNC-RZ50N camera. All goes fine but around the time I get 8MB of data the video disappears. This is because the camera stops sending it (I confirmed through Wireshark). However the RTCP packets seem to be still going. > > I use VLC to stream from the same camera and it seems to stream on forever. I do realize VLC uses Live555 so unsure why it behaves differently. It may be because VLC also sends periodic (null) "GET_PARAMETER" commands, whereas openRTSP does not. The camera is probably using these "GET_PARAMETER" commands as a sign that the client is still alive. The basic problem is that the "Sony SNC-RZ50N camera" is buggy. It should be using incoming RTCP "RR" packets - from the client - as a sign of client liveness. PLEASE REPORT THIS BUG TO SONY, and ask them to fix their camera. (I presume that you've already checked whether a firmware upgrade is available.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkordani at lsa2.com Fri Nov 22 19:53:05 2013 From: jkordani at lsa2.com (Joshua Kordani) Date: Fri, 22 Nov 2013 22:53:05 -0500 Subject: [Live-devel] Sony SNC-RZ50N RTSP stream stopping Message-ID: I've had this problem with other Sony SNC model cameras. They are aware of the problem and won't fix it Ross Finlayson 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 oopdeveloper at hotmail.com Sun Nov 24 15:28:09 2013 From: oopdeveloper at hotmail.com (Michael) Date: Sun, 24 Nov 2013 18:28:09 -0500 Subject: [Live-devel] getNormalPlayTime returning negative value Message-ID: I have a project that implements some FramedSource subclasses to send compressed audio and video. On the receiving side, a subclass of the MediaSink class provides the ability to receive the compressed data and perform playback. The getNormalPlayTime method is called on the receiving side to determine the timestamps for the stream samples. This has worked great until I recently upgraded the Live555 libs from version 2012.10.22 to version 2013.11.06. After the migration, the getNormalPlayTime method returns a negative value after receiving a small amount of samples. Is this a known issue? I haven't tried the 2013.11.15 version as the release notes did not indicate any related changes. As I have not migrated my client side code yet to the asynchronous calls, I only upgraded the server side to version 2013.11.06. When switching the server side back to version 2012.10.22, the problem does not exist. Thanks and great work! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Nov 24 21:09:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 24 Nov 2013 21:09:35 -0800 Subject: [Live-devel] getNormalPlayTime returning negative value In-Reply-To: References: Message-ID: > As I have not migrated my client side code yet to the asynchronous calls, I only upgraded the server side to version 2013.11.06. Sorry, but the latest version of the code is the only version that we support. So, you'll need to upgrade your client to use the latest version (with the asynchronous RTSP client interface, which has existed for 3 1/2 years now). In the meantime, if you want to test your server with a RTSP client that uses the latest version of the code, then you can do so using the "testRTSPClient" demo application. If you compile this with "DEBUG_PRINT_NPT" defined, then it will display the 'normal play time' for each frame (as well as 'presentation time'). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.nemec at atlas.cz Sun Nov 24 23:45:44 2013 From: a.nemec at atlas.cz (=?utf-8?q?Alexandr_N=C4=9Bmec?=) Date: Mon, 25 Nov 2013 08:45:44 +0100 Subject: [Live-devel] =?utf-8?q?RFC_2435_compliance?= Message-ID: <20131125084544.4B50941E@atlas.cz> Dear Ross, ? we came across an interesting issue with JPEG video (transmitted via RTP) not being decoded correctly. We tracked down this issue to the fact, that live555 seems to use different default JPEG quantizer tables (luma and chroma - see JPEGVideoRTPSource.cpp line 271, latest source code) than defined in RFC 2435 Appendix A. The algorithm of generating the resulting quantizer tables is, however, the same. So for RTP JPEG implementations using Q values <= 127, the resulting JPEG frames are distorted. ? Could you please explain the difference here? We use live555?(the openRTSP application)?as a reference for proving RTSP/RTP standard compliance, but I have never noticed this difference before. ? Thank you very much. ? Alex From finlayson at live555.com Mon Nov 25 01:11:48 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 25 Nov 2013 01:11:48 -0800 Subject: [Live-devel] RFC 2435 compliance In-Reply-To: <20131125084544.4B50941E@atlas.cz> References: <20131125084544.4B50941E@atlas.cz> Message-ID: <7FBD1C75-1872-48DA-9183-C3188B86F372@live555.com> This same question (I think) came up last January. Here is the answer that I gave at that time: http://lists.live555.com/pipermail/live-devel/2013-January/016400.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.nemec at atlas.cz Mon Nov 25 03:12:59 2013 From: a.nemec at atlas.cz (=?utf-8?q?Alexandr_N=C4=9Bmec?=) Date: Mon, 25 Nov 2013 12:12:59 +0100 Subject: [Live-devel] =?utf-8?q?RFC_2435_compliance?= In-Reply-To: <7FBD1C75-1872-48DA-9183-C3188B86F372@live555.com> References: <20131125084544.4B50941E@atlas.cz> <7FBD1C75-1872-48DA-9183-C3188B86F372@live555.com> Message-ID: <20131125121259.38ED5867@atlas.cz> > This same question (I think) came up last January. ?Here is the answer that I gave at that time: ? Thanks for your quick reply. Sorry, I googled through the archives, but did not find this one. The "zigzag" idea is the correct answer, as this order is required for the JPEG DQT segment. So Live555 is absolutely correct here, but it turns out, that the code in Appendix A of RFC 2435 omits to use the reordered tables when creating?jpeg headers, ie. it contains a bug. I just could not believe that a RFC code example can contain a bug. ? Thanks. ? Best regards ? Alex From umar at janteq.com Mon Nov 25 10:06:23 2013 From: umar at janteq.com (Umar Qureshey) Date: Mon, 25 Nov 2013 18:06:23 +0000 Subject: [Live-devel] Sony SNC-RZ50N RTSP stream stopping In-Reply-To: References: Message-ID: Yes, the firmware version is the latest for that model. From bruno.abreu at livingdata.pt Mon Nov 25 12:54:50 2013 From: bruno.abreu at livingdata.pt (Bruno Abreu) Date: Mon, 25 Nov 2013 20:54:50 -0000 Subject: [Live-devel] Server socket not closed after TCP request from client Message-ID: <882534b150fcf1bef7d630988d959b8c.squirrel@www.livingdata.pt> Hello Ross, while trying to replicate a problem that occasionally arises with a small set of streaming servers, we detected something that might be an issue with LIVE555. Those servers are behind a firewall which blocks UDP packets (not under our control). So the clients request data via TCP, not UDP. On occasion the servers block or crash. We still have to delve deeper into this and so, trying to replicate this situation in our own environment, we ran testOnDemandRTSPServer and used openRTSP as the client with the following parameters: $ ./openRTSP -d 10 -t rtsp://:8554/h264ESVideoTest What we've noticed is that after the TEARDOWN from each client we can see a socket left in CLOSE_WAIT state. Since we're using a script (attached) that calls openRTSP repeatedly, the number of CLOSE_WAIT sockets increases as the clients continue to make requests. The trick here seems to be the conjunction of the -d and -t flags. $ lsof -i testOnDem 32741 smartcodec 3u IPv4 8466411 0t0 TCP *:8554 (LISTEN) testOnDem 32741 smartcodec 4u IPv4 8466414 0t0 TCP *:8000 (LISTEN) testOnDem 32741 smartcodec 5u IPv4 8466417 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47728 (CLOSE_WAIT) testOnDem 32741 smartcodec 6r IPv4 8466664 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47731 (CLOSE_WAIT) testOnDem 32741 smartcodec 7u IPv4 8466674 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47732 (CLOSE_WAIT) testOnDem 32741 smartcodec 8u IPv4 8466700 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47735 (CLOSE_WAIT) testOnDem 32741 smartcodec 9u IPv4 8466425 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47729 (CLOSE_WAIT) testOnDem 32741 smartcodec 10r IPv4 8466708 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47736 (CLOSE_WAIT) testOnDem 32741 smartcodec 11u IPv4 8466744 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47739 (CLOSE_WAIT) testOnDem 32741 smartcodec 12u IPv4 8466681 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47733 (CLOSE_WAIT) ... testOnDem 32741 smartcodec 80u IPv4 8467707 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47808 (ESTABLISHED) testOnDem 32741 smartcodec 83u IPv4 8467712 0t0 UDP *:6972 testOnDem 32741 smartcodec 84u IPv4 8467713 0t0 UDP *:6973 testOnDem 32741 smartcodec 85u IPv4 8467715 0t0 TCP smartcodec-ddt2:8554->smartcodec-ddt2:47809 (ESTABLISHED) testOnDem 32741 smartcodec 87u IPv4 8467721 0t0 UDP *:6974 testOnDem 32741 smartcodec 88u IPv4 8467722 0t0 UDP *:6975 Eventually, the limit of open sockets is reached and, when that happens, the server usually blocks using a lot of CPU. Streaming stops and no more client connections are accepted. Although, once, I've seen the server crash. Sorry I didn't collect a core dump so I could print a back-trace. I've also attached the logs from the server (class RTSPServer compiled with DEBUG flag) after a run with the limit of open file descriptors set to 32. Also, please notice the following change made to ByteStreamFileSource.cpp so that our server could run continuously with a small file: @@ -91,8 +91,9 @@ void ByteStreamFileSource::doGetNextFrame() { if (feof(fFid) || ferror(fFid) || (fLimitNumBytesToStream && fNumBytesToStream == 0)) { - handleClosure(this); - return; + // handleClosure(this); + // return; + rewind(fFid); } This doesn't seem to be the cause of our own server blocks/crashes, but we thought we should report. Thank you, Bruno Abreu -- Living Data - Sistemas de Informa??o e Apoio ? Decis?o, Lda. LxFactory - Rua Rodrigues de Faria, Mobile: +351 963428802 103, edif?cio I - 4? piso Phone: +351 213622163 1300-501 LISBOA Fax: +351 213622165 Portugal URL: www.livingdata.pt -------------- next part -------------- A non-text attachment was scrubbed... Name: openRTSP-testOnDemand.sh Type: application/x-shellscript Size: 1054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testOnDemandRTSPServer.log.gz Type: application/x-gzip Size: 12570 bytes Desc: not available URL: From warren at etr-usa.com Mon Nov 25 14:04:50 2013 From: warren at etr-usa.com (Warren Young) Date: Mon, 25 Nov 2013 15:04:50 -0700 Subject: [Live-devel] Server socket not closed after TCP request from client In-Reply-To: <882534b150fcf1bef7d630988d959b8c.squirrel@www.livingdata.pt> References: <882534b150fcf1bef7d630988d959b8c.squirrel@www.livingdata.pt> Message-ID: <5293C982.4050909@etr-usa.com> On 11/25/2013 13:54, Bruno Abreu wrote: > > What we've noticed is that after the TEARDOWN from each client we can see a > socket left in CLOSE_WAIT state. That means the client sent FIN, the server stack sent ACK, and nothing else happened. Because TCP is bidirectional, the server is allowed to continue sending data to the client, but in most protocols, the server closes down its sending half shortly after the client sends its FIN, indicating that it won't be sending any more data. A quick peek into the networking code suggests the problem may be in Groupsock::handleRead(). There isn't an "else" clause at line 312 in Groupsock.cpp, handling a 0 return from readSocket(), which is what happens when the server stack gets that FIN. From f.saeidinik at gmail.com Mon Nov 25 06:48:15 2013 From: f.saeidinik at gmail.com (Foad SaeidiNik) Date: Mon, 25 Nov 2013 18:18:15 +0330 Subject: [Live-devel] Implement a real time app using live555 Message-ID: Hi , I want to implement a real time application which server streams it's music to clients , and clients should play this stream exactly simultaneously.After a lot of search , I found live555 for my purpose.After some experience with it , I finally figured out that I can use from testMP3Streamer as my server and testMP3Receiver or testRTSPClient as my client. But the clients just output the stream to the STDOUT or to my custom file and they don't play it. I played this music in VLC environment(by URL rtp://... or rtsp://...) , But VLC is not real time , and my clients does not play it simultaneously. How can I play this stream exactly simultaneously? Tnx -- Foad Saeidi Nik Under Graduate Student in Information Technology Dept of Electrical and Computer Engineering, University of Tehran -------------- next part -------------- An HTML attachment was scrubbed... URL: From brilliantov at byterg.ru Tue Nov 26 00:52:36 2013 From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich) Date: Tue, 26 Nov 2013 12:52:36 +0400 Subject: [Live-devel] Every 2 frame is truncated Message-ID: <52946154.9030000@byterg.ru> Hello! I use live555 2013.10.25 on my FreeScale iMX53 board. My encoded programm put data to shared memory, access to data control semaphore. For get data from shared memory I write class based on FramedSource and doGetNextFrame function. Program is a very simple: in_addr ipv4 = {0}; ipv4.s_addr = our_inet_addr(destination); Groupsock gp(*env, ipv4, Port(port), ttl); gp.multicastSendOnly(); OutPacketBuffer::maxSize = 1280 * 720 * 3 / 2; RTPSink* h264 = H264VideoRTPSink::createNew(*env, &gp, 96); Frame *frame = new Frame(semaphore, sh_mem, *env); // my class H264VideoStreamFramer* video_src = H264VideoStreamFramer::createNew(*env, frame); h264->startPlaying(*video_src, NULL, NULL); env->taskScheduler().doEventLoop(&is_stop); shared memory: _data semaphore: _sem void Frame::doGetNextFrame() { if (NULL == _data || NULL == _sem) { handleClosure(this); return; } fFrameSize = 0; fNumTruncatedBytes = 0; if (_last_frame != _data->frame && !sem_wait(_sem)) { fFrameSize = _data->size; if (fFrameSize > fMaxSize) { fNumTruncatedBytes = fFrameSize - fMaxSize; daemon_info("frame %u, truncated %u bytes, max %u, size %u", _data->frame,fNumTruncatedBytes, fMaxSize, fFrameSize); fFrameSize = fMaxSize; } gettimeofday(&fPresentationTime, NULL); daemon_debug("%s: start copy frame %u %lu.%lu", __PRETTY_FUNCTION__,_data->frame,fPresentationTime.tv_sec, fPresentationTime.tv_usec); memcpy(fTo, _data->data, fFrameSize); gettimeofday(&fPresentationTime, NULL); daemon_debug("%s: stop copy frame %u (%u bytes) %lu.%lu", __PRETTY_FUNCTION__, _data->frame, fFrameSize,fPresentationTime.tv_sec, fPresentationTime.tv_usec); _last_frame = _data->frame; sem_post(_sem); gettimeofday(&fPresentationTime, NULL); } nextTask() = envir().taskScheduler().scheduleDelayedTask( 40000, (TaskFunc*)FramedSource::afterGetting, this); } It work, but every 2 frame I see that frame truncated: streamerd: virtual void Frame::doGetNextFrame(): start copy frame 79 12670.159867 streamerd: virtual void Frame::doGetNextFrame(): stop copy frame 79 (126794 bytes) 12670.163626 streamerd: frame 80, truncated 113146 bytes, max 23204, size 136350 streamerd: virtual void Frame::doGetNextFrame(): start copy frame 80 12670.306181 streamerd: virtual void Frame::doGetNextFrame(): stop copy frame 80 (23204 bytes) 12670.307837 streamerd: virtual void Frame::doGetNextFrame(): start copy frame 81 12670.369945 streamerd: virtual void Frame::doGetNextFrame(): stop copy frame 81 (110216 bytes) 12670.379823 streamerd: frame 82, truncated 79271 bytes, max 39782, size 119053 streamerd: virtual void Frame::doGetNextFrame(): start copy frame 82 12670.434736 streamerd: virtual void Frame::doGetNextFrame(): stop copy frame 82 (39782 bytes) 12670.436576 Why and how can I solve this problem? Thank you and excuse me for my bad english. -- Best regards, Brilliantov Kirill Vladimirovich From finlayson at live555.com Tue Nov 26 12:48:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 26 Nov 2013 10:48:18 -1000 Subject: [Live-devel] Server socket not closed after TCP request from client In-Reply-To: <882534b150fcf1bef7d630988d959b8c.squirrel@www.livingdata.pt> References: <882534b150fcf1bef7d630988d959b8c.squirrel@www.livingdata.pt> Message-ID: <5CA6DA2F-6E6C-451D-9122-FA44F7124585@live555.com> Thanks for the report. This was, indeed, a bug that accidentally got introduced back in July. I've just installed a new version - 2013.11.26 - of the "LIVE555 Streaming Media" code that fixes this bug. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 26 13:02:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 26 Nov 2013 11:02:09 -1000 Subject: [Live-devel] Fixed a serious security bug in the "LIVE555 Streaming Media" code. PLEASE UPGRADE ASAP! Message-ID: <67798979-B0B3-4797-AEFC-D816B9F57014@live555.com> The latest version - 2013.11.26 - of the "LIVE555 Streaming Media" code fixes a serious potential buffer-overflow bug in the RTSP command parsing code. This bug could potentially allow an attacker (with a malicious RTSP client or server) to cause cause arbitrary code to be executed in your own RTSP server or client. IMPORTANT NOTE: All LIVE555-based applications that include a RTSP client or RTSP server should ***upgrade to this latest version ASAP***! (The bug affected RTSP clients as well as RTSP servers, because RTSP clients can also receive commands.) Many thanks to iSEC Partners for discovering and reporting this bug. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 26 13:10:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 26 Nov 2013 11:10:15 -1000 Subject: [Live-devel] Every 2 frame is truncated In-Reply-To: <52946154.9030000@byterg.ru> References: <52946154.9030000@byterg.ru> Message-ID: > H264VideoStreamFramer* video_src = > H264VideoStreamFramer::createNew(*env, frame); This is your main problem. Because your input source delivers encoded H.264 NAL units - one at a time - you should be feeding it into a "H264VideoStreamDiscreteFramer", not a "H264VideoStreamFramer". > nextTask() = envir().taskScheduler().scheduleDelayedTask( > 40000, (TaskFunc*)FramedSource::afterGetting, this); You should not be doing this. Instead, you should be letting the "RTPSink" object calculate the appropriate time to delay. To do this, you should set "fDurationInMicroseconds" for each NAL unit that you deliver, and then - at the end - just call FramedSource::afterGetting(this); > Thank you and excuse me for my bad english. Your English is good (much better than my Russian :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 26 13:34:10 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 26 Nov 2013 11:34:10 -1000 Subject: [Live-devel] Implement a real time app using live555 In-Reply-To: References: Message-ID: > Hi , I want to implement a real time application which server streams it's music to clients , and clients should play this stream exactly simultaneously.After a lot of search , I found live555 for my purpose.After some experience with it , I finally figured out that I can use from testMP3Streamer as my server and testMP3Receiver or testRTSPClient as my client. But the clients just output the stream to the STDOUT or to my custom file and they don't play it. The data output - to 'stdout' - consists of encoded MP3 audio frames (because that's what was transmitted (inside RTP packets) by the server). To 'play' this data, you need to feed it into a decoder (which we don't supply). That's what media players (such as VLC, Winamp, etc.) do. > I played this music in VLC environment(by URL rtp://... or rtsp://...) , But VLC is not real time , and my clients does not play it simultaneously. How can I play this stream exactly simultaneously? Right now, you can't. There has been recent work in the IETF to make this possible (see ), but we don't currently support this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglan at yahoo.com Tue Nov 26 19:22:04 2013 From: zanglan at yahoo.com (Lan Zang) Date: Wed, 27 Nov 2013 11:22:04 +0800 (SGT) Subject: [Live-devel] To get statistics of the input sources? Message-ID: <1385522524.557.YahooMailNeo@web193303.mail.sg3.yahoo.com> Hi, Ross, I am trying to get the total bytes or packets received by the RTSP server. I know that I can get the statistics from RTPReceptionStatsDB of RTPSource or its sub-classes. I just need to know if there is any path I can get the data directly from ServerMediaSession or ServerMediaSubsession? Or if there is any way to get input RTPSources used by these 2 classes? (They do use SimpleRTPSource as input.) Best Regards, Lan Zang(Sander) -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.saeidinik at gmail.com Tue Nov 26 23:08:34 2013 From: f.saeidinik at gmail.com (Foad SaeidiNik) Date: Wed, 27 Nov 2013 10:38:34 +0330 Subject: [Live-devel] Implement a real time app using live555 In-Reply-To: References: Message-ID: Tnx for your answer , but is there any method or another library or player which I can use it to play a stream simultanseouly? Like wireless speaker which are connected to TV! On Wed, Nov 27, 2013 at 1:04 AM, Ross Finlayson wrote: > Hi , I want to implement a real time application which server streams it's > music to clients , and clients should play this stream exactly > simultaneously.After a lot of search , I found live555 for my purpose.After > some experience with it , I finally figured out that I can use from > testMP3Streamer as my server and testMP3Receiver or testRTSPClient as my > client. But the clients just output the stream to the STDOUT or to my > custom file and they don't play it. > > > The data output - to 'stdout' - consists of encoded MP3 audio frames > (because that's what was transmitted (inside RTP packets) by the server). > To 'play' this data, you need to feed it into a decoder (which we don't > supply). That's what media players (such as VLC, Winamp, etc.) do. > > > I played this music in VLC environment(by URL rtp://... or rtsp://...) , > But VLC is not real time , and my clients does not play it simultaneously. > How can I play this stream exactly simultaneously? > > > Right now, you can't. There has been recent work in the IETF to make this > possible (see < > https://ietf.org/doc/draft-ietf-avtcore-idms/?include_text=1>), but we > don't currently support this. > > 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 > > -- Under Graduate Student in Information Technology Dept of Electrical and Computer Engineering, University of Tehran -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkordani at lsa2.com Wed Nov 27 13:10:47 2013 From: jkordani at lsa2.com (Joshua Kordani) Date: Wed, 27 Nov 2013 16:10:47 -0500 Subject: [Live-devel] Sony SNC-RZ50N RTSP stream stopping In-Reply-To: References: Message-ID: <52965FD7.8080902@lsa2.com> I've also upgraded the firmware on my hardware, specifically the snc ch180 model camera, and been on the phone with support numerous times. Originally, in the case of our model, the default rtsp timeout value used by the camera defaulted to "never", which in our application resulted in numerous, unstoppable streams being created over the life of the system, as network connectivity would drop and connections be reset. The answer to that problem was to specify a timeout value on the camera, but once we did that, we discovered that the streams would time out in spite of being sent periodic normal rtsp control packets. We noticed that VLC worked, but our custom client did not, and upon consulting with Sony support, were told "tough", and to use some other method (the details of which I wasn't privy to but could reproduce if desired) of keeping the stream alive. These cameras may look pretty, and perhaps provide decent picture, but the physical behavior and the API is really junky and frankly not indicative of the price you pay for them On 11/25/13 1:06 PM, Umar Qureshey wrote: > Yes, the firmware version is the latest for that model. > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -- Joshua Kordani LSA Autonomy -------------- next part -------------- An HTML attachment was scrubbed... URL: From brilliantov at byterg.ru Thu Nov 28 04:06:02 2013 From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich) Date: Thu, 28 Nov 2013 16:06:02 +0400 Subject: [Live-devel] RTP MJPEG: incorrect framerate Message-ID: <529731AA.6050807@byterg.ru> Hello! I use live555 2013.10.25 on my FreeScale iMX53 board. Now I add MJPEG RTP stream, for this I write class based on JPEGVideoSource with doGetNextFrame, afterGettingFrame and afterGettingFrame1 functions. void JPEG::doGetNextFrame() { fFrameSize = 0; //_src is a class based on FramedSource _src->getNextFrame(fTo, fMaxSize, afterGettingFrame, this, FramedSource::handleClosure, this); } void JPEG::afterGettingFrame(void* clientData, unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds) { JPEG *source = static_cast(clientData); source->afterGettingFrame1(frameSize, numTruncatedBytes, presentationTime, durationInMicroseconds); } void JPEG::afterGettingFrame1(unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds) { size_t header_len = 0; fFrameSize = frameSize; if (jpeg_param_from_header(fTo, fFrameSize, &header_len)) { fFrameSize -= header_len; memmove(fTo, &fTo[header_len], fFrameSize); fNumTruncatedBytes = numTruncatedBytes; fPresentationTime.tv_sec = presentationTime.tv_sec; fPresentationTime.tv_usec = presentationTime.tv_usec; fDurationInMicroseconds = durationInMicroseconds; *_env << "duration " << fDurationInMicroseconds << "\n"; } FramedSource::afterGetting(this); } Follow programm output: ..... duration 119947 duration 80010 duration 79983 ..... For view RTP stream I use follow GStreamer pipeline: gst-launch -v udpsrc multicast-group=224.1.4.6 port=5000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, payload=(int)96, encoding-name=(string)JPEG" ! rtpjpegdepay ! ffdec_mjpeg ! xvimagesink Unfortunally programm exit with message "Internal data flow error". GStreamer output: .......... /GstPipeline:pipeline0/GstRtpJPEGDepay:rtpjpegdepay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, payload=(int)96, encoding-name=(string)JPEG /GstPipeline:pipeline0/GstRtpJPEGDepay:rtpjpegdepay0.GstPad:src: caps = image/jpeg, framerate=(fraction)0/1, width=(int)1280, height=(int)720 ** (gst-launch-0.10:10622): WARNING **: offset=12 should be less then plen=12 ** (gst-launch-0.10:10622): CRITICAL **: gst_adapter_push: assertion `GST_IS_BUFFER (buf)' failed /GstPipeline:pipeline0/ffdec_mjpeg:ffdec_mjpeg0.GstPad:sink: caps = image/jpeg, framerate=(fraction)0/1, width=(int)1280, height=(int)720 /GstPipeline:pipeline0/ffdec_mjpeg:ffdec_mjpeg0.GstPad:src: caps = video/x-raw-yuv, width=(int)1280, height=(int)720, framerate=(fraction)0/1, format=(fourcc)Y42B, interlaced=(boolean)false I see correct resolution 1280x720, but framerate not correct. Why and how can I solve this proble? Thank you and excuse me for my bad english. -- Best regards, Brilliantov Kirill Vladimirovich From nambirajan.manickam at i-velozity.com Thu Nov 28 04:36:00 2013 From: nambirajan.manickam at i-velozity.com (Nambirajan M) Date: Thu, 28 Nov 2013 18:06:00 +0530 Subject: [Live-devel] Current play time in FF and REW Message-ID: <005901ceec36$692d2b00$3b878100$@manickam@i-velozity.com> Hi Ross, We need to get the current video play time (getNormalPlayTime) from the RTSPServer side and send to the client side in the response to a GET_PARAMETER call (handleCmd_GET_PARAMETER() )during trick play. The client may be a 3rd party client which is trying to display the current video time during FF and REW. "Is there a function that is equivalent to MediaSubsession::getNormalPlayTime() on the server side? To determine the normal play time - at the server side." Thanks and regards, M. Nambirajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From oopdeveloper at hotmail.com Wed Nov 27 03:26:41 2013 From: oopdeveloper at hotmail.com (Michael) Date: Wed, 27 Nov 2013 06:26:41 -0500 Subject: [Live-devel] live-devel Digest, Vol 121, Issue 24 In-Reply-To: References: Message-ID: I upgraded the server to the 2013.11.15 version of the code and ran the testRTSPClient built with the same version and the DEBUG_PRINT_NPT flag. This is what I'm seeing: Opening connection to 127.0.0.1, port 8554... ...remote connection opened Sending request: DESCRIBE rtsp://127.0.0.1:8554/stream RTSP/1.0 CSeq: 2 User-Agent: testRTSPClient.exe (LIVE555 Streaming Media v2013.11.25) Accept: application/sdp Received 611 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, Nov 27 2013 03:36:49 GMT Content-Base: rtsp://127.0.0.1:8554/stream/ Content-Type: application/sdp Content-Length: 449 v=0 o=- 1385523390905109 1 IN IP4 192.166.17.77 s=TestDescription i=TestInfo t=0 0 a=tool:LIVE555 Streaming Media v2013.11.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:TestDescription a=x-qt-text-inf:TestInfo m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=42C00C;sprop-parameter-sets=Z0LADNsFB+ wEQAAAAwBAAAAHo8UKuA==,aMqDyyA= a=control:track1 [URL:"rtsp://127.0.0.1:8554/stream/"]: Got a SDP description: v=0 o=- 1385523390905109 1 IN IP4 192.166.17.77 s=TestDescription i=TestInfo t=0 0 a=tool:LIVE555 Streaming Media v2013.11.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:TestDescription a=x-qt-text-inf:TestInfo m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=42C00C;sprop-parameter-sets=Z0LADNsFB+ wEQAAAAwBAAAAHo8UKuA==,aMqDyyA= a=control:track1 RTCPInstance[004BA5B8]::RTCPInstance() schedule(2.381796->1385523411.742420) [URL:"rtsp://127.0.0.1:8554/stream/"]: Initiated the "video/H264" subsession (client ports 59242-59243) Sending request: SETUP rtsp://127.0.0.1:8554/stream/track1 RTSP/1.0 CSeq: 3 User-Agent: testRTSPClient.exe (LIVE555 Streaming Media v2013.11.25) Transport: RTP/AVP;unicast;client_port=59242-59243 Received 197 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, Nov 27 2013 03:36:49 GMT Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=59242-592 43;server_port=6970-6971 Session: A21575F2 [URL:"rtsp://127.0.0.1:8554/stream/"]: Set up the "video/H264" subsession (client ports 59242-59243) [URL:"rtsp://127.0.0.1:8554/stream/"]: Created a data sink for the "video/H264" subsession Sending request: PLAY rtsp://127.0.0.1:8554/stream/ RTSP/1.0 CSeq: 4 User-Agent: testRTSPClient.exe (LIVE555 Streaming Media v2013.11.25) Session: A21575F2 Range: npt=0.000- [004BA5B8]saw incoming RTCP packet (from address 127.0.0.1, port 6971) 80c80006 f3c75135 d63fe751 5ffa6df0 208c02ca 00000000 00000000 81ca0005 f3c75135 010a4661 6e637950 616e7473 00000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0xf3c75135 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xf3c75135 validated entire RTCP packet Received 182 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, Nov 27 2013 03:36:49 GMT Range: npt=0.000- Session: A21575F2 RTP-Info: url=rtsp://127.0.0.1:8554/stream/track1;seq=40774;rtptime=546046694 [URL:"rtsp://127.0.0.1:8554/stream/"]: Started playing session... Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 2235 bytes. Presentation time: 1385523409.375226 NPT: 0.000000 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 2094 bytes. Presentation time: 1385523409.375237 NPT: 0.000011 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 2593 bytes. Presentation time: 1385523409.375237 NPT: 0.000011 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 177 bytes. Presentation time: 1385523409.394325 NPT: 0.019099 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 167 bytes. Presentation time: 1385523409.394336 NPT: 0.019110 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 195 bytes. Presentation time: 1385523409.394336 NPT: 0.019110 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 332 bytes. Presentation time: 1385523409.416891 NPT: 0.041665 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 351 bytes. Presentation time: 1385523409.416891 NPT: 0.041665 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 409 bytes. Presentation time: 1385523409.416902 NPT: 0.041676 [004BA5B8]saw incoming RTCP packet (from address 127.0.0.1, port 6971) 80c80006 f3c75135 d63fe753 ac23e9ea 6f5132fc 0000000c 00002172 81ca0005 f3c75135 010a4661 6e637950 616e7473 00000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0xf3c75135 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xf3c75135 validated entire RTCP packet Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 467 bytes. Presentation time: 1385508727.891801 NPT: -14681.483425 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 493 bytes. Presentation time: 1385508727.891801 NPT: -14681.483425 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 547 bytes. Presentation time: 1385508727.891812 NPT: -14681.483414 schedule(0.428738->1385523412.171732) Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 513 bytes. Presentation time: 1385508727.910934 NPT: -14681.464292 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 588 bytes. Presentation time: 1385508727.910945 NPT: -14681.464281 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 625 bytes. Presentation time: 1385508727.910956 NPT: -14681.464270 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 605 bytes. Presentation time: 1385508727.930178 NPT: -14681.445048 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 673 bytes. Presentation time: 1385508727.930178 NPT: -14681.445048 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 629 bytes. Presentation time: 1385508727.930189 NPT: -14681.445037 sending REPORT sending RTCP packet 81c90007 cd93888a f3c75135 ffffffff 00019f5a 00000dc7 e753ac23 00007da4 81ca0005 cd93888a 010a4661 6e637950 616e7473 00000000 schedule(1.212250->1385523413.390580) Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 611 bytes. Presentation time: 1385508727.952577 NPT: -14681.422649 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 693 bytes. Presentation time: 1385508727.952588 NPT: -14681.422638 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 670 bytes. Presentation time: 1385508727.952599 NPT: -14681.422627 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 623 bytes. Presentation time: 1385508727.971776 NPT: -14681.403450 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 662 bytes. Presentation time: 1385508727.971787 NPT: -14681.403439 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 650 bytes. Presentation time: 1385508727.971798 NPT: -14681.403428 Stream "rtsp://127.0.0.1:8554/stream/"; video/H264: Received 661 bytes. Presentation time: 1385508727.990986 NPT: -14681.384240 ------------------------------ Message: 4 Date: Sun, 24 Nov 2013 21:09:35 -0800 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] getNormalPlayTime returning negative value Message-ID: Content-Type: text/plain; charset="us-ascii" > As I have not migrated my client side code yet to the asynchronous calls, I only upgraded the server side to version 2013.11.06. Sorry, but the latest version of the code is the only version that we support. So, you'll need to upgrade your client to use the latest version (with the asynchronous RTSP client interface, which has existed for 3 1/2 years now). In the meantime, if you want to test your server with a RTSP client that uses the latest version of the code, then you can do so using the "testRTSPClient" demo application. If you compile this with "DEBUG_PRINT_NPT" defined, then it will display the 'normal play time' for each frame (as well as 'presentation time'). Ross Finlayson Live Networks, Inc. http://www.live555.com/ ******** From cmatsuura at vivint.com Wed Nov 27 11:46:22 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Wed, 27 Nov 2013 12:46:22 -0700 Subject: [Live-devel] All client streams slow down when using two live proxies connected together. Message-ID: <52964C0E.6050002@vivint.com> Hi Ross, I have a question. Running two live555proxyServers and clients. Using both openRTSP and gstreamer as clients. Here is my setup. * live proxy 1 (openRTSP 172.16.10.100) connect to camera * Client 1 (172.16.10.100) connected to live proxy 1 (172.16.10.100) * live proxy 2 (192.168.3.250) connect to live proxy 1 * Client 2 (gstream client 192.168.3.25) connect to live proxy 2 Both client 1 and client 2 slow down, when client 2 connects. Is there a setting or configuration I can use to solve this problem. slow down is much worse with client 2 is a gst playbin2. We have seen this on other types of clients connecting TCP (as client 2). We have a configuration where we need a proxy at once source and a proxy at a different source. We want to use the same code base from live555. We initial had different implementations, one based on live555 and another based on a different rtsp server, and did not have and slow down issues, but had other problems. Below are the outputs and calling parameters on the proxies and openRTSP (client). Thanks,. Craig Client are connecting via TCP (-t). ------------------------------------ 192.168.3.250> ./openRTSP -V -t -Q -d 10 rtsp://192.168.3.250:8554/Video Opened URL "rtsp://192.168.3.250:8554/Video", returning a SDP description: v=0 o=- 1385580361225980 1 IN IP4 192.168.3.250 s=LIVE555 Streaming Media v2013.11.26 i=LIVE555 Streaming Media v2013.11.26 t=0 0 a=tool:LIVE555 Streaming Media v2013.11.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.11.26 a=x-qt-text-inf:LIVE555 Streaming Media v2013.11.26 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64401F;sprop-parameter-sets=J2RAH6wsagFAFumoKDAqAAAH0gAB1MAo,KO4EYsA= a=control:track1 Created receiver for "video/H264" subsession (client ports 39104-39105) Setup "video/H264" subsession (client ports 39104-39105) Created output file: "video-H264-1" Started playing session Receiving streamed data (for up to 10.000000 seconds)... begin_QOS_statistics subsession video/H264 num_packets_received 290 num_packets_lost 0 elapsed_measurement_time 10.001134 kBytes_received_total 372.718000 measurement_sampling_interval_ms 1000 kbits_per_second_min 0.000000 kbits_per_second_ave 298.140591 kbits_per_second_max 1154.382976 packet_loss_percentage_min 0.000000 packet_loss_percentage_ave 0.000000 packet_loss_percentage_max 0.000000 inter_packet_gap_ms_min 0.002000 inter_packet_gap_ms_ave 26.072645 inter_packet_gap_ms_max 2007.246000 end_QOS_statistics First live Proxy on pointed to second live proxy (Note 192.168.3.216 is port forward from the 172.16.10.100) ------------------------------------------------------------------------------------------------------------ 192.168.3.250> ./live555ProxyServer.x86 rtsp://192.168.3.216/Video LIVE555 Proxy Server (LIVE555 Streaming Media library version 2013.11.26) RTSP stream, proxying the stream "rtsp://192.168.3.216/Video" Play this stream using the URL: rtsp://192.168.3.250:8554/Video (We use port 8000 for optional RTSP-over-HTTP tunneling.) Second live Proxy pointed to camera to stream --------------------------------------------- root at touchlink-847e405d04f4:~# ./live555ProxyServer -V rtsp://172.16.10.101:554/ live.sdpADDRCONF(NETDEV_CHANGE): eth0: link becomes ready LIVE555 Proxy Server (LIVE555 Streaming Media library version 2013.11.26) Opening connection to 172.16.10.101, port 554... RTSP stream, proxying the stream "rtsp://172.16.10.101:554/live.sdp" Play this stream using the URL: rtsp://172.16.10.100/Video (We use port 80 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://172.16.10.101:554/live.sdp RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Accept: application/sdp Received 510 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, 27 Nov 2013 12:25:5 GMT Content-Base: rtsp://172.16.10.101/live.sdp/ Content-Type: application/sdp Content-Length: 348 v=0 o=RTSP 1385555105 945 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 98 b=AS:0 a=rtpmap:98 H264/90000 a=control:trackID=1 a=fmtp:98 packetization-mode=1; profile-level-id=64401f; sprop-parameter-sets=J2RAH6wsagFAFumoKDAqAAAH0gAB1MAo,KO4EYsA= ProxyServerMediaSession["rtsp://172.16.10.101/live.sdp/"] added new "ProxyServerMediaSubsession" for RTP/video/H264 track Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Received 145 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, 27 Nov 2013 12:25:35 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 3097014589) Sending request: SETUP rtsp://172.16.10.101/live.sdp/trackID=1 RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Transport: RTP/AVP;unicast;client_port=56926-56927 ProxyServerMediaSubsession["H264"]::createNewRTPSink() Received 169 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, 27 Nov 2013 12:25:43 GMT Session: 15618451;timeout=70 Transport: RTP/AVP;unicast;client_port=56926-56927;server_port=5580-5581 ProxyRTSPClient["rtsp://172.16.10.101/live.sdp/"]::continueAfterSETUP(): head codec: H264; numSubsessions 1 queue: H264 Sending request: PLAY rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Session: 15618451 Received 201 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, 27 Nov 2013 12:25:43 GMT Session: 15618451;timeout=70 RTP-Info: url=rtsp://172.16.10.101/live.sdp/trackID=1;seq=0;rtptime=0 Range: npt=0- RTCP-Interval: 250 Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 6 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Session: 15618451 Received 144 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, 27 Nov 2013 12:26:3 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 7 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Session: 15618451 Received 145 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 7 Date: Wed, 27 Nov 2013 12:26:41 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 8 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Session: 15618451 Received 145 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 8 Date: Wed, 27 Nov 2013 12:27:35 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 9 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Session: 15618451 Received 145 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 9 Date: Wed, 27 Nov 2013 12:28:27 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 10 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Session: 15618451 Received 145 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 10 Date: Wed, 27 Nov 2013 12:29:1 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 11 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Session: 15618451 Received 145 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 11 Date: Wed, 27 Nov 2013 12:30:1 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0 CSeq: 12 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26) Session: 15618451 Received 146 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 12 Date: Wed, 27 Nov 2013 12:30:40 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN -------------- next part -------------- An HTML attachment was scrubbed... URL: From brilliantov at byterg.ru Fri Nov 29 03:44:54 2013 From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich) Date: Fri, 29 Nov 2013 15:44:54 +0400 Subject: [Live-devel] RTP MJPEG: strange fourcc format Y42B instead I420 Message-ID: <52987E36.8030303@byterg.ru> Hello! I use live555 2013.10.25 on my FreeScale iMX53 board. Now I add MJPEG RTP stream, for this I write class based on JPEGVideoSource. For view RTP stream I use follow GStreamer pipeline: gst-launch -v udpsrc multicast-group=224.1.4.6 port=5000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, payload=(int)96, encoding-name=(string)JPEG" ! rtpjpegdepay ! ffdec_mjpeg ! xvimagesink I compare pipeline output from live555 stream and GStreamer stream and found difference in fourcc: GStreamer: caps = video/x-raw-yuv, width=(int)1280, height=(int)720, framerate=(fraction)0/1, format=(fourcc)I420, interlaced=(boolean)false live555: caps = video/x-raw-yuv, width=(int)1280, height=(int)720, framerate=(fraction)0/1, format=(fourcc)Y42B, interlaced=(boolean)false Unfortunally on http://www.fourcc.org/yuv.php I found very short information about Y42B: Weitek format listed as "YUV 4:2:2 planar". I have no other information on this format. But why I get this difference if I use one codec? -- Best regards, Brilliantov Kirill Vladimirovich From brilliantov at byterg.ru Fri Nov 29 03:48:09 2013 From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich) Date: Fri, 29 Nov 2013 15:48:09 +0400 Subject: [Live-devel] RTP MJPEG: incorrect framerate Message-ID: <52987EF9.7030100@byterg.ru> Ok, I compare GStreamer pipeline output from GStreamer and live555 RTP stream, both contained framerate in this format. I think this question may be closed. Thank you. -- Best regards, Brilliantov Kirill Vladimirovich From Guy.Bonneau at miranda.com Fri Nov 29 11:31:40 2013 From: Guy.Bonneau at miranda.com (Guy.Bonneau at miranda.com) Date: Fri, 29 Nov 2013 14:31:40 -0500 Subject: [Live-devel] RFC 2435 compliance In-Reply-To: <20131125121259.38ED5867@atlas.cz> References: <20131125084544.4B50941E@atlas.cz> <7FBD1C75-1872-48DA-9183-C3188B86F372@live555.com> <20131125121259.38ED5867@atlas.cz> Message-ID: There is no issue with the RFC 2435 Appendix A neither with the live555 procedure to scale a quantization table with a Q factor. Both are correct.. If you read the header of Appendix A it clearly states the reason of the example code : "The following code can be used to create a quantization table from a Q factor..." Now when you recompute the quantization table from a selected Q factor your only scale the 64 quantization values by the same factor. Doing the procedure on zigzag order on doing it on "standard" non-zigzag order doesn't matter. It will yield the same "scaled quantization factor". Jpeg encoding/decoding of spectral component of the picture operate on block of 64 values. Those value must be processed in zigzag order. If you use a zigzaged table then the encoding/decoding only increment the index of the quantization value in the table to get the good quantization value. However if you use a non-zigzag table then the encoding/decoding must find and pick-up the good quantization inside the table. This is up to the implementation of the code. Guy Bonneau From: Alexandr N?mec To: LIVE555 Streaming Media - development & use , Date: 2013-11-25 07:06 Subject: Re: [Live-devel] RFC 2435 compliance Sent by: live-devel-bounces at ns.live555.com > This same question (I think) came up last January. Here is the answer that I gave at that time: Thanks for your quick reply. Sorry, I googled through the archives, but did not find this one. The "zigzag" idea is the correct answer, as this order is required for the JPEG DQT segment. So Live555 is absolutely correct here, but it turns out, that the code in Appendix A of RFC 2435 omits to use the reordered tables when creating jpeg headers, ie. it contains a bug. I just could not believe that a RFC code example can contain a bug. Thanks. Best regards Alex _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 11498465 at qq.com Thu Nov 28 03:13:26 2013 From: 11498465 at qq.com (=?gb18030?B?wffUxtCmLzpE?=) Date: Thu, 28 Nov 2013 19:13:26 +0800 Subject: [Live-devel] playback 1080p mkv file problem Message-ID: Hi, I download the newest live555MediaServer.exe to playback *.mkv(1920x1080 264, aac) file, with using vlc as rtsp client, and I found the video have some mosaic always. From the server command windows, it display to increase the OutPacketBuffer::maxSize. So I download the new version source code(live2013.11.26), and modified it to 1024000, also modified BANK_SIZE to 2048000 and fill the FramedSource::maxFrameSize() { return 1024000}. After compiled the mediaServer.exe, I found the problem also. The test 1080p.mkv file in the attachment, and I'am sure the file ok. So, how to solve the problem? Waiting for your reply, thanks very much! ------------------ ZhangTao USG? INC. TEL: 010 - 6266 9403 - 807 MOB: 131 6423 1356 ?QQ????????? 1080p.mkv (185.47M, 2013?12?28? 18:12 ??)???????http://mail.qq.com/cgi-bin/ftnExs_download?k=0c35376308b25c96d34698634031064d06560054000150531f045550021c000601011a025750074f01540f520352065b5651045766383453020d0713485c5f143208&t=exs_ftn_download&code=257cf14b -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 29 12:21:33 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Nov 2013 10:21:33 -1000 Subject: [Live-devel] playback 1080p mkv file problem In-Reply-To: References: Message-ID: <354F760A-D13C-48FF-877B-05D947E8AB70@live555.com> Unfortunately I wasn't able to download your "1080p.mkv" file. When I tried, I got an error message "The file is too large to download directly. Recommend you to use tools to download it." Could you please try putting your file on another web site (for downloading)? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 29 12:35:54 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Nov 2013 10:35:54 -1000 Subject: [Live-devel] Current play time in FF and REW In-Reply-To: <005901ceec36$692d2b00$3b878100$@manickam@i-velozity.com> References: <005901ceec36$692d2b00$3b878100$@manickam@i-velozity.com> Message-ID: <7D24E941-A2FD-4962-B85C-AC91EA6F8691@live555.com> > We need to get the current video play time (getNormalPlayTime) from the RTSPServer side and send to the client side in the response to a GET_PARAMETER call (handleCmd_GET_PARAMETER() )during trick play. The client may be a 3rd party client which is trying to display the current video time during FF and REW. Note that a standards-compliant client does not need to do this. Instead, it can use the normal "RTP-Info:"+RTP timestamp+RTCP mechanism, that our clients implement (using our "MediaSubsession::getNormalPlayTime()" function). Please contact the manufacturer of your '3rd party client', telling them that they shouldn't need to use this "GET_PARAMETER" hack. (If they have any questions about this, tell them to contact me.) > ?Is there a function that is equivalent to MediaSubsession::getNormalPlayTime() on the server side? To determine the normal play time ? at the server side.? No. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 29 13:05:30 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Nov 2013 11:05:30 -1000 Subject: [Live-devel] getNormalPlayTime returning negative value In-Reply-To: References: Message-ID: <3A132FC7-7637-4605-85FA-086A9B2E0199@live555.com> (First, when replying to a mailing list digest, please use a proper "Subject:" line. (In this case, I've corrected it for you.)) I suspect that the cause of your problem is that your H.264 video source object - on your server - is setting incorrect "fPresentationTime" values. It's important that these "fPresentationTime" values be ***aligned with wall-clock time*** - i.e., the time that you would get by calling "gettimeofday()". (The reason for this is that our RTCP implementation uses "gettimeofday()" times.) The server's clock doesn't have to be in sync with the rest of the world (i.e., via the Network Time Protocol (NTP)). But it's important that the "fPresentationTime" values be aligned with the server's clock. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 29 13:10:23 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Nov 2013 11:10:23 -1000 Subject: [Live-devel] All client streams slow down when using two live proxies connected together. In-Reply-To: <52964C0E.6050002@vivint.com> References: <52964C0E.6050002@vivint.com> Message-ID: > I have a question. Running two live555proxyServers and clients. Using both openRTSP and gstreamer as clients. > > Here is my setup. > live proxy 1 (openRTSP 172.16.10.100) connect to camera > Client 1 (172.16.10.100) connected to live proxy 1 (172.16.10.100) > live proxy 2 (192.168.3.250) connect to live proxy 1 I don't know why you're connecting one proxy server to another. This should work OK, but probably shouldn't need to be doing this... > Client 2 (gstream client 192.168.3.25) connect to live proxy 2 > > Both client 1 and client 2 slow down, when client 2 connects. I don't know what you mean by "slow down", but I suspect that - when you connected a second client to "live proxy 1", the duplicated network traffic exceeded the TCP capacity of your network (between "live proxy 1" and its two clients ("client 1" and "live proxy 2"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 29 13:15:51 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Nov 2013 11:15:51 -1000 Subject: [Live-devel] RTP MJPEG: incorrect framerate In-Reply-To: <529731AA.6050807@byterg.ru> References: <529731AA.6050807@byterg.ru> Message-ID: <3B2012AA-22D1-4DEA-A843-F309FCCFAA83@live555.com> > I use live555 2013.10.25 This (like all old versions of the code) contain a security hole. Please upgrade to the latest version of the code. > Now I add MJPEG RTP stream, for this I write class based on > JPEGVideoSource I presume you mean "subclassed from JPEGVideoSource", not "based on JPEGVideoSource". Note also that your class must deliver JPEG frames *without the usual JPEG header*. However, please read: http://www.live555.com/liveMedia/faq.html#jpeg-streaming JPEG streaming is a bad idea, and is discouraged. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Sat Nov 30 10:59:48 2013 From: cmatsuura at vivint.com (Craig Matsuura) Date: Sat, 30 Nov 2013 11:59:48 -0700 Subject: [Live-devel] Liveness times out Message-ID: <529A35A4.9010100@vivint.com> Ross, If there are no clients (sessions) connected to the rtsp proxy, would a DESCRIBE command keep alive the camera better than an OPTIONS? I have noticed the OPTIONS command has no Sessions attribute at times, probably due to no clients connected. I have 8-9 camera's connected to the live555proxy and at times the liveness timer exceeds the timeout, which causes a camera to not stay alive even though it accepts OPTIONS commands. As from what I understand and can see in the proxy code it uses a DESCRIBE to re-establish ability for the camera to stream (have a session). I know what the standard answer is there is a bug in the camera firmware, but if the proxy is late in delivering the OPTIONS I don't see how this could be a camera firmware bug. Unless OPTIONS commands should fail if you exceed the timeout? Should the connection close on the camera once the timeout has been exceeded? I'm experiencing a bug where the liveness exceeds the timeout reported by the camera and the camera will not stream once a client connects (expected behavior if not kept alive). (This is not a problem on the camera as I have verified if you send the Liveness within the reported timeout from the camera, the camera will allow sessions to connect and stream). I have two solutions one I have implemented and the other is using a DESCRIBE when there is no session, but I have not tried the DESCRIBE, seemed weird to try. My first solution was to keep track in the proxy rtsp client how long it takes to send out liveness (OPTIONS). The event loop must have some long calls that exceed the time out of any times setup, so the OPTIONS command go out late causing the camera to not stay alive. My solution is to time how long it takes between liveness commands and if it exceeds the timeout (reported by the camera) or the default of the 60 secs. This seems to work well, when we exceed the timeout I call the continueAfterLivenessCommand(-1, fServerSupportsGetParameter) method (using -1 to get a log message, could use 1 like the subsessionByeHandler() ) to reset the camera connection. I thought a DESCRIBE might work if not in a session, but was not sure and it felt like a hack vs my first solution. I think the real issue is the event loop. ( Used syslog to log all the verbose logs to see timestamps, this is how I caught the problem) How do you get around the event loop taking too long once it get's to the alarms to process? Currently I'm only handling 8-9 cameras with the proxy, but at times the timeout for the liveness exceeds the time set for the scheduleDelayedTask() for the sendLivenessCommand. It seems to be a bigger problem for camera's on wifi with poor connectivity. However I do see from the perspective of the proxy it is taking significantly longer to send the actually OPTIONS (Liveness) than expected (not consistently slow). I have one other scheduleDelayedTask() that is every two seconds (but this is only done once). So I doubt it is any tasks I have added. It does appear to be the handlers registered or the select timeout is way higher than the timeout required for the alarms. Thanks, Craig Thanks, Craig