From ranshalit at gmail.com Sun Jul 1 05:56:49 2012 From: ranshalit at gmail.com (Ran Shalit) Date: Sun, 1 Jul 2012 15:56:49 +0300 Subject: [Live-devel] SAP - session announcement protocol Message-ID: Hello, Is SAP - session announcement protocol supported in Live555 streaming media ? Best Regards, Ran From finlayson at live555.com Sun Jul 1 20:31:11 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 1 Jul 2012 20:31:11 -0700 Subject: [Live-devel] SAP - session announcement protocol In-Reply-To: References: Message-ID: <1D9FECF9-0EF5-480D-BFCE-AE512210E8AD@live555.com> > Is SAP - session announcement protocol supported in Live555 streaming media ? We have a demo application - "sapWatch" - that will read and display SAP announcements, but we don't have any direct support for creating and sending SAP announcements; you would need to program that yourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjh431 at gmail.com Mon Jul 2 00:08:38 2012 From: sjh431 at gmail.com (jhseo) Date: Mon, 2 Jul 2012 16:08:38 +0900 Subject: [Live-devel] Question about proxyserver. Message-ID: <014301cd5821$8370df70$8a529e50$@gmail.com> Hi. Forward / Backward random seeking is supported in LIVE555 Proxy server? In my case,, Seeking bar is activated by modifying the "virtual float duration( ) const; however, the command of client( "PAUSE" or "PLAY") did not send to back-end LIVE555 Server. To do this, what shall I modify in Proxy Server Source code? Thanks for your interest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 2 00:41:34 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 2 Jul 2012 00:41:34 -0700 Subject: [Live-devel] Question about proxyserver. In-Reply-To: <014301cd5821$8370df70$8a529e50$@gmail.com> References: <014301cd5821$8370df70$8a529e50$@gmail.com> Message-ID: > Forward / Backward random seeking is supported in LIVE555 Proxy server? No, it's not - because the purpose of the "LIVE555 Proxy Server" is to share a single 'back-end' stream amongst possibly several concurrent 'front-end' streams. If you want to seek within a RTSP stream, then don't proxy it. Instead, access the stream directly. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.lc at vaelsys.com Mon Jul 2 00:46:24 2012 From: jesus.lc at vaelsys.com (=?ISO-8859-1?Q?Jes=FAs_Legan=E9s?=) Date: Mon, 2 Jul 2012 09:46:24 +0200 Subject: [Live-devel] Set ProxyServerMediaSession::fProxyRTSPClient as protected In-Reply-To: <57A1ECC3-87BC-4B23-A847-BB7C13D9EB6D@live555.com> References: <57A1ECC3-87BC-4B23-A847-BB7C13D9EB6D@live555.com> Message-ID: > So if you want to detect/log every client connection (etc.) to the proxy > server, then you would not modify (or subclass) the "Proxy*" code at all. > Instead, you would subclass "RTSPServer" and > "RTSPServer::RTSPClientSession", and reimplement the "handleCmd_SETUP()" > (etc.) virtual functions. > Correctly, and i have this done already :-) At this moment i'm able to detect and log this way connections between clients and the proxy, and now i need to detect and log connections between the proxy and the remote camera (the 'back-end' server as you say). > But if your intention is instead to detect/log only connections from the > proxy server to the 'back-end' server (which is only a subset of the number > of connections from front-end clients to the proxy server), then: > Yes, exactly what i want to do :-) > The fact is that reviewing the code it seems to me it's the correct > aproach, just use a ProxyServerMediaSession child constructor that > inits ProxyServerMediaSession::fProxyRTSPClient to my own > ProxyRTSPClient child class > > > Yes, but note that the existing "ProxyServerMediaSession" constructor > already initializes the "fProxyRTSPClient" field (to a new "ProxyRTSPClient" > object), so you'll need to delete this (using "Medium::close()") first, > before assigning your new "ProxyRTSPClient" subclass object. > Oh, i didn't thought about it, thanks for the advice... :-) > But hold on: At present, the "ProxyRTSPClient" class is defined only inside > the "ProxyServerMediaSession.cpp" file, not in a header file, so you > shouldn't even have the ability to access it, let alone subclass it. So, > are you sure that this is something that you really want to do?? > Well, i don't know if there's a better (or at least a different) way to do this, but if it's the only way to be able to detect and log the connections from the proxy to the remote back-end server (the camera) and you can't be able to suggest to me any other way to do it, then yes, this and the redefination of RTSPClient::sendRequest() method in a subclass is what i want to do :-) But i'm open to ideas, too... :-D -- Jes?s Legan?s Combarro Software developer at Vaelsys From bruno at maxcom.hr Mon Jul 2 01:34:52 2012 From: bruno at maxcom.hr (Bruno Babic) Date: Mon, 02 Jul 2012 10:34:52 +0200 Subject: [Live-devel] Is there something like WindowsUsageEnvironment? In-Reply-To: References: <57A1ECC3-87BC-4B23-A847-BB7C13D9EB6D@live555.com> Message-ID: <4FF15D2C.4080405@maxcom.hr> Hi! What would be the best way to get openRTSP client to run as a GUI tool under Windows? Should I try to create something like WindowsUsageEnvironment to handle Windows message pool? Has anyone already did anything like that? -- 2b||!2b? From naresh at vizexperts.com Mon Jul 2 02:32:58 2012 From: naresh at vizexperts.com (Naresh Sankapelly) Date: Mon, 2 Jul 2012 15:02:58 +0530 Subject: [Live-devel] Is there something like WindowsUsageEnvironment? In-Reply-To: <4FF15D2C.4080405@maxcom.hr> References: <57A1ECC3-87BC-4B23-A847-BB7C13D9EB6D@live555.com> <4FF15D2C.4080405@maxcom.hr> Message-ID: <000901cd5835$ac0370b0$040a5210$@com> You could use VLC. Thanks Naresh Ph. 8884199804 -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Bruno Babic Sent: Monday, July 02, 2012 2:05 PM To: LIVE555 Streaming Media - development & use Subject: [Live-devel] Is there something like WindowsUsageEnvironment? Hi! What would be the best way to get openRTSP client to run as a GUI tool under Windows? Should I try to create something like WindowsUsageEnvironment to handle Windows message pool? Has anyone already did anything like that? -- 2b||!2b? _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From ajax.chai at alcatel-lucent.com Mon Jul 2 02:59:48 2012 From: ajax.chai at alcatel-lucent.com (Chai, Zheng (Ajax)) Date: Mon, 2 Jul 2012 11:59:48 +0200 Subject: [Live-devel] About the H264 over RTP FA Message-ID: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBAFA96@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Dear Live555 DEV, First thank you give the guide line on how to let Live555 to take input from a live source (H264 pictures over RTP) http://www.live555.com/liveMedia/faq.html#liveInput-unicast. I followed this guideline and made it successfully to receive the H264/RTP Live Stream from a live source (which sends Single NAL Unit Packet). However, I encountered one problem as following and need your help and clarification. The problem is: if I send H264 over RTP/UDP with Fragmentation Units (FUs-A) then Live555 failed to parse this live stream. I have to use FUs-A since Single NAL unit packet is less network efficient, and I will seperate the source H264/RTP/UDP package into FUs-As and send them one by one to Live555. Please give some suggestions on that how to make Live555 receive/parse FUs-A. Thanks a lot. It will be appreciated if you can point me some existing codes examples on this. BR Ajax Chai From finlayson at live555.com Mon Jul 2 07:47:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 2 Jul 2012 07:47:20 -0700 Subject: [Live-devel] About the H264 over RTP FA In-Reply-To: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBAFA96@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> References: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBAFA96@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Message-ID: I find your message confusing, because here you're talking about transmitting H.264 over RTP: > First thank you give the guide line on how to let Live555 to take input from a live source (H264 pictures over RTP) http://www.live555.com/liveMedia/faq.html#liveInput-unicast. But here you're talking about *receiving* H.264 over RTP: > I followed this guideline and made it successfully to receive the H264/RTP Live Stream from a live source (which sends Single NAL Unit Packet). And here you seem to be talking about both transmitting and receiving, but I'm not sure: > The problem is: if I send H264 over RTP/UDP with Fragmentation Units (FUs-A) then Live555 failed to parse this live stream. But anyway, the important thing to understand is that our software *automatically* handles the fragmentation (when transmitting) and defragmentation (when receiving) H.264 NAL units. Your application software (which uses our software) *should not* deal with FU-A NAL units at all. In particular: - When transmitting H.264 over RTP, you should deliver your (unfragmented!) NAL units - one at a time - to a "H264VideoStreamDiscreteFramer", and then into a "H264VideoRTPSink". - When receiving H.64 over RTP, you use a "H264VideoRTPSource". Any fragmented NAL units in the RTP stream will automatically be defragmented before delivery. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.lc at vaelsys.com Mon Jul 2 09:28:00 2012 From: jesus.lc at vaelsys.com (=?ISO-8859-1?Q?Jes=FAs_Legan=E9s?=) Date: Mon, 2 Jul 2012 18:28:00 +0200 Subject: [Live-devel] Set ProxyServerMediaSession::fProxyRTSPClient as protected In-Reply-To: References: <57A1ECC3-87BC-4B23-A847-BB7C13D9EB6D@live555.com> Message-ID: >> Yes, but note that the existing "ProxyServerMediaSession" constructor >> already initializes the "fProxyRTSPClient" field (to a new "ProxyRTSPClient" >> object), so you'll need to delete this (using "Medium::close()") first, >> before assigning your new "ProxyRTSPClient" subclass object. >> > Oh, i didn't thought about it, thanks for the advice... :-) > I have been talking with my boss and we got a better solution to this: instead of set the constructor to protected, redefine it and close the previous connection before create the new one, have this connection created on a protected method so only is needed to be overloaded just this method, so the connection is only done one time and also the constructor gets untouched :-) -- Jes?s Legan?s Combarro Software developer at Vaelsys From mboom at channelislands.com Mon Jul 2 12:25:49 2012 From: mboom at channelislands.com (Michael L. Boom) Date: Mon, 2 Jul 2012 12:25:49 -0700 Subject: [Live-devel] Trick Play and the Live 555 Server Message-ID: I am writing a proxy for VOD servers. I am using the Live 555 server for testing. The version I have is about 1 year old. How can I tell, from the source code, what version I have? If I say play range npt=30-60 at scale 1 it works. If I say play range npt=30-60 at scale 2 it goes way beyond 60 before it stops. Is (or was) this a bug or am I using it wrong. Also, what player would you suggest to test the rewind. The VLC player doesn't seem to support it (or am I using that wrong also). Can you recommend any other free RTSP servers that I can test with? If I want to play backwards from time 60 to time 30 do I just say Range: npt=60-30 or Range: npt=30-60? What scale should I use for rewind? Any info would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 2 13:43:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 2 Jul 2012 13:43:20 -0700 Subject: [Live-devel] Trick Play and the Live 555 Server In-Reply-To: References: Message-ID: <13D9EA45-1A61-4C1B-95F0-D838CD00AD6C@live555.com> > I am writing a proxy for VOD servers. I am using the Live 555 server for testing. The version I have is about 1 year old. How can I tell, from the source code, what version I have? See http://www.live555.com/liveMedia/faq.html#latest-version As noted in the FAQ, only the latest version of the code is supported. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Mon Jul 2 14:29:29 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Mon, 02 Jul 2012 23:29:29 +0200 Subject: [Live-devel] RTSP connection management issue Message-ID: <4FF22ED90200004D0006EB37@pta-emo.csir.co.za> Hi Ross, If an RTSP request belonging to an established session is sent over a new TCP connection, the server seems to respond with a "405 Method Not Allowed". According to the RFC, RTSP requests can be transmitted in several different ways including one connection per request/response transaction? This is especially a problem on android devices that experience connection issues. It seems network issues *sometimes* cause subsequent RTSP requests to be sent over a new connection resulting in the 405 response. We've observed this using VLC on android (which uses live555) and replicated it with a python script using the *latest* version of the live555 RTSP server. Output re-using connection: OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 02 2012 21:20:10 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 02 2012 21:20:10 GMT Content-Base: rtsp://127.0.0.1:8554/test.aac/ Content-Type: application/sdp Content-Length: 518 v=0 o=- 1341255550959061 1 IN IP4 192.168.1.16 s=AAC Audio, streamed by the LIVE555 Media Server i=test.aac t=0 0 a=tool:LIVE555 Streaming Media v2012.06.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:AAC Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:test.aac m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 MPEG4-GENERIC/44100/2 a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 a=control:track1 SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 02 2012 21:20:10 GMT Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=43754-43755;server_port=6970-6971 Session: 269EF060 PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Mon, Jul 02 2012 21:20:10 GMT Range: npt=0.000- Session: 269EF060 RTP-Info: url=rtsp://127.0.0.1:8554/test.aac/track1;seq=27747;rtptime=3310178955 TEARDOWN response: RTSP/1.0 200 OK CSeq: 6 Date: Mon, Jul 02 2012 21:20:12 GMT Output with new connections per request: OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 02 2012 21:23:20 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 02 2012 21:23:20 GMT Content-Base: rtsp://127.0.0.1:8554/test.aac/ Content-Type: application/sdp Content-Length: 518 v=0 o=- 1341255550959061 1 IN IP4 192.168.1.16 s=AAC Audio, streamed by the LIVE555 Media Server i=test.aac t=0 0 a=tool:LIVE555 Streaming Media v2012.06.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:AAC Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:test.aac m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 MPEG4-GENERIC/44100/2 a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 a=control:track1 SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 02 2012 21:23:20 GMT Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=43754-43755;server_port=6970-6971 Session: 4BF1E275 PLAY response: RTSP/1.0 405 Method Not Allowed CSeq: 5 Date: Mon, Jul 02 2012 21:23:20 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER TEARDOWN response: RTSP/1.0 405 Method Not Allowed CSeq: 6 Date: Mon, Jul 02 2012 21:23:22 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER If it helps, I could send you the python script to replicate the issue. Do you consider this to be a bug? Best regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From finlayson at live555.com Mon Jul 2 21:28:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 2 Jul 2012 21:28:15 -0700 Subject: [Live-devel] Set ProxyServerMediaSession::fProxyRTSPClient as protected In-Reply-To: References: <57A1ECC3-87BC-4B23-A847-BB7C13D9EB6D@live555.com> Message-ID: OK, I've now installed a new version (2012.07.03) of the code that does the following: - The definition of "ProxyRTSPClient" is now publicly accessible, in the "ProxyServerMediaSession.hh" header file - so you can subclass it if you wish. - "ProxyServerMediaSession" now has a new virtual function "createNewProxyRTSPClient()", for creating its new "ProxyRTSPClient" object. The default implementation of this function just creates a new "ProxyRTSPClient", but you can redefine this (in a subclass of "ProxyServerMediaSession") to create a new subclass object instead. - The "fProxyRTSPClient" and "fClientMediaSession" member variables of "ProxyServerMediaSession" are now protected. - "RTSPClient::sendRequest()" is now a virtual function, and "protected:", rather than "private:". I hope this now allows you to do what you want with your subclasses... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 2 21:33:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 2 Jul 2012 21:33:05 -0700 Subject: [Live-devel] RTSP connection management issue In-Reply-To: <4FF22ED90200004D0006EB37@pta-emo.csir.co.za> References: <4FF22ED90200004D0006EB37@pta-emo.csir.co.za> Message-ID: > Do you consider this to be a bug? Well, because the server doesn't properly handle client behavior that's legal, then I suppose you could consider this to be a bug, yes. Unfortunately, fixing this is going to be non-trivial, so it may take a while... > If it helps, I could send you the python script to replicate the issue. Yes, please do; that will help me test out the new ('fixed') server implementation. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aashish.Kaushik at hcl.com Mon Jul 2 22:50:51 2012 From: Aashish.Kaushik at hcl.com (Aashish Kaushik) Date: Tue, 3 Jul 2012 11:20:51 +0530 Subject: [Live-devel] FW: issue in live555 proxyserver Message-ID: <8706360947A56E45B1418C635D365964023F2E1CF182@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN> hi Ross, Thank you very much for the quick responses, coming to point playing streaming directly I don't see any problem but I when using proxy in between then I could see this problem, meanwhile I will try with quick player and let you, it may be true that VLC might be giving problem. Thanks, Krist. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Saturday, June 30, 2012 2:13 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] issue in live555 proxyserver >From what I can tell, the "LIVE555 Proxy Server" is working properly. Are you able to successfully play the stream directly from the 'back-end' server - i.e., not using a proxy server? Note that recent versions of VLC seem to have a problem playing MPEG-4 video streams. If you're using VLC, and find that you have a problem playing the stream directly (i.e., not using a proxy), then I suggest trying QuickTime Player instead. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Tue Jul 3 01:49:52 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Tue, 03 Jul 2012 10:49:52 +0200 Subject: [Live-devel] RTSP connection management issue Message-ID: <4FF2CE500200004D0006EBD8@pta-emo.csir.co.za> Hi Ross, Thanks for the quick response. > Unfortunately, fixing this is going to be non-trivial, so it may take a while... I figured as much after stepping through the code briefly. > > If it helps, I could send you the python script to replicate the issue. > Yes, please do; that will help me test out the new ('fixed') server implementation. Please find attached the python script used for replication. Note that it is a quick hack containing the openRTSP requests obtained with the test.aac file available from live555, which it assumes to be in the mediaServer directory. Command line parameters: -n uses new connections per request and defaults to False -p can be used to set the port which defaults to 554 -s can be used to change the server defaults to 127.0.0.1 Cheers, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: rtsp_client.py Type: application/octet-stream Size: 2636 bytes Desc: not available URL: From ajax.chai at alcatel-lucent.com Tue Jul 3 02:00:14 2012 From: ajax.chai at alcatel-lucent.com (Chai, Zheng (Ajax)) Date: Tue, 3 Jul 2012 11:00:14 +0200 Subject: [Live-devel] live-devel Digest, Vol 105, Issue 2 In-Reply-To: References: Message-ID: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBAFDBF@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Ross, Thanks for your reply and sorry for the confusing. Let me clarify. My scenarios is as following, 1) I created a Android based program to capture and encode H264 NAL units; 2) On Android, I seperate the H264 NAL units to Fragmentation Units (FUs-A standard based) and send these FUs-A packages by RTP/UDP via my own RTP wrapper, to Live555 server; 3) While on Live555 server side, I wrote a new H264 Source follow the http://www.live555.com/liveMedia/faq.html#liveInput-unicast. to receive the above H264-FUs-A/RTP; 4) Also on Live555 server side, I had a H264VideoRTPSink; The problem is on step 2) & 3), when live555 received the FUs-A, it cannot delivery successfully to the H264VideoRTPSink if I use FUs-A. However, if I didn't do the fragmentation on android (send each H264 NAL units by one RTP package), then it works well. Please help. Best Regards Ajax Chai =============================================================================== Message: 4 Date: Mon, 2 Jul 2012 07:47:20 -0700 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] About the H264 over RTP FA Message-ID: Content-Type: text/plain; charset="us-ascii" I find your message confusing, because here you're talking about transmitting H.264 over RTP: > First thank you give the guide line on how to let Live555 to take input from a live source (H264 pictures over RTP) http://www.live555.com/liveMedia/faq.html#liveInput-unicast. But here you're talking about *receiving* H.264 over RTP: > I followed this guideline and made it successfully to receive the H264/RTP Live Stream from a live source (which sends Single NAL Unit Packet). And here you seem to be talking about both transmitting and receiving, but I'm not sure: > The problem is: if I send H264 over RTP/UDP with Fragmentation Units (FUs-A) then Live555 failed to parse this live stream. But anyway, the important thing to understand is that our software *automatically* handles the fragmentation (when transmitting) and defragmentation (when receiving) H.264 NAL units. Your application software (which uses our software) *should not* deal with FU-A NAL units at all. In particular: - When transmitting H.264 over RTP, you should deliver your (unfragmented!) NAL units - one at a time - to a "H264VideoStreamDiscreteFramer", and then into a "H264VideoRTPSink". - When receiving H.64 over RTP, you use a "H264VideoRTPSource". Any fragmented NAL units in the RTP stream will automatically be defragmented before delivery. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Mon, 2 Jul 2012 18:28:00 +0200 From: Jes?s Legan?s To: "LIVE555 Streaming Media - development & use" Subject: Re: [Live-devel] Set ProxyServerMediaSession::fProxyRTSPClient as protected Message-ID: Content-Type: text/plain; charset=ISO-8859-1 >> Yes, but note that the existing "ProxyServerMediaSession" constructor >> already initializes the "fProxyRTSPClient" field (to a new "ProxyRTSPClient" >> object), so you'll need to delete this (using "Medium::close()") >> first, before assigning your new "ProxyRTSPClient" subclass object. >> > Oh, i didn't thought about it, thanks for the advice... :-) > I have been talking with my boss and we got a better solution to this: instead of set the constructor to protected, redefine it and close the previous connection before create the new one, have this connection created on a protected method so only is needed to be overloaded just this method, so the connection is only done one time and also the constructor gets untouched :-) -- Jes?s Legan?s Combarro Software developer at Vaelsys ------------------------------ Message: 6 Date: Mon, 2 Jul 2012 12:25:49 -0700 From: "Michael L. Boom" To: Subject: [Live-devel] Trick Play and the Live 555 Server Message-ID: Content-Type: text/plain; charset="iso-8859-1" I am writing a proxy for VOD servers. I am using the Live 555 server for testing. The version I have is about 1 year old. How can I tell, from the source code, what version I have? If I say play range npt=30-60 at scale 1 it works. If I say play range npt=30-60 at scale 2 it goes way beyond 60 before it stops. Is (or was) this a bug or am I using it wrong. Also, what player would you suggest to test the rewind. The VLC player doesn't seem to support it (or am I using that wrong also). Can you recommend any other free RTSP servers that I can test with? If I want to play backwards from time 60 to time 30 do I just say Range: npt=60-30 or Range: npt=30-60? What scale should I use for rewind? Any info would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 7 Date: Mon, 2 Jul 2012 13:43:20 -0700 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Trick Play and the Live 555 Server Message-ID: <13D9EA45-1A61-4C1B-95F0-D838CD00AD6C at live555.com> Content-Type: text/plain; charset="iso-8859-1" > I am writing a proxy for VOD servers. I am using the Live 555 server for testing. The version I have is about 1 year old. How can I tell, from the source code, what version I have? See http://www.live555.com/liveMedia/faq.html#latest-version As noted in the FAQ, only the latest version of the code is supported. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 8 Date: Mon, 02 Jul 2012 23:29:29 +0200 From: "Ralf Globisch" To: Subject: [Live-devel] RTSP connection management issue Message-ID: <4FF22ED90200004D0006EB37 at pta-emo.csir.co.za> Content-Type: text/plain; charset=US-ASCII Hi Ross, If an RTSP request belonging to an established session is sent over a new TCP connection, the server seems to respond with a "405 Method Not Allowed". According to the RFC, RTSP requests can be transmitted in several different ways including one connection per request/response transaction? This is especially a problem on android devices that experience connection issues. It seems network issues *sometimes* cause subsequent RTSP requests to be sent over a new connection resulting in the 405 response. We've observed this using VLC on android (which uses live555) and replicated it with a python script using the *latest* version of the live555 RTSP server. Output re-using connection: OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 02 2012 21:20:10 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 02 2012 21:20:10 GMT Content-Base: rtsp://127.0.0.1:8554/test.aac/ Content-Type: application/sdp Content-Length: 518 v=0 o=- 1341255550959061 1 IN IP4 192.168.1.16 s=AAC Audio, streamed by the LIVE555 Media Server i=test.aac t=0 0 a=tool:LIVE555 Streaming Media v2012.06.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:AAC Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:test.aac m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 MPEG4-GENERIC/44100/2 a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 a=control:track1 SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 02 2012 21:20:10 GMT Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=43754-43755;server_port=6970-6971 Session: 269EF060 PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Mon, Jul 02 2012 21:20:10 GMT Range: npt=0.000- Session: 269EF060 RTP-Info: url=rtsp://127.0.0.1:8554/test.aac/track1;seq=27747;rtptime=3310178955 TEARDOWN response: RTSP/1.0 200 OK CSeq: 6 Date: Mon, Jul 02 2012 21:20:12 GMT Output with new connections per request: OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 02 2012 21:23:20 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 02 2012 21:23:20 GMT Content-Base: rtsp://127.0.0.1:8554/test.aac/ Content-Type: application/sdp Content-Length: 518 v=0 o=- 1341255550959061 1 IN IP4 192.168.1.16 s=AAC Audio, streamed by the LIVE555 Media Server i=test.aac t=0 0 a=tool:LIVE555 Streaming Media v2012.06.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:AAC Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:test.aac m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 MPEG4-GENERIC/44100/2 a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 a=control:track1 SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 02 2012 21:23:20 GMT Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=43754-43755;server_port=6970-6971 Session: 4BF1E275 PLAY response: RTSP/1.0 405 Method Not Allowed CSeq: 5 Date: Mon, Jul 02 2012 21:23:20 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER TEARDOWN response: RTSP/1.0 405 Method Not Allowed CSeq: 6 Date: Mon, Jul 02 2012 21:23:22 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER If it helps, I could send you the python script to replicate the issue. Do you consider this to be a bug? Best regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. ------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 105, Issue 2 ****************************************** From finlayson at live555.com Tue Jul 3 02:12:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Jul 2012 02:12:47 -0700 Subject: [Live-devel] About the H264 over RTP FA In-Reply-To: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBAFDBF@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> References: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBAFDBF@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Message-ID: <489ABC76-6837-4E98-BC61-4119D4EC2C4F@live555.com> > The problem is on step 2) & 3), when live555 received the FUs-A, it cannot delivery successfully to the H264VideoRTPSink if I use FUs-A. Remember that - to receive H.264/RTP packets - you must use a "H264VideoRTPSource" object. If you are doing this, and you find that the "H264VideoRTPSource" object is not defragmenting the FU-A fragments properly, then perhaps the incoming H.264/RTP are not properly formed - i.e., do not properly conform to the H.264 RTP payload format?? Because you are not using our software to construct and stream the H.264/RTP packets towards our server, then we can't help you here; you're going to have to figure out for yourself why "H264VideoRTPSource" is not behaving as expected. Sorry. (But Remember, You Have Complete Source Code.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dushyanth.subramanya at gmail.com Tue Jul 3 08:04:02 2012 From: dushyanth.subramanya at gmail.com (dushyanth) Date: Tue, 3 Jul 2012 11:04:02 -0400 Subject: [Live-devel] Regarding the build In-Reply-To: References: Message-ID: In the instructions to build and run the libraries for windows, the second point says "If the 'tools' directory on your Windows machine is something *other than*"c:\Program Files\DevStudio\Vc", change the "TOOLS32 =" line in the file "win32config" " where can i expect to find this directory. Is it the tools folder in my visual studio package? Thanks. -- Dushyanth Subramanya University of Pennsylvania Class of 2012 School of Engineering & Applied Science MSE, MCIT www.seas.upenn.edu/~dushs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranshalit at gmail.com Tue Jul 3 13:20:59 2012 From: ranshalit at gmail.com (Ran Shalit) Date: Tue, 3 Jul 2012 22:20:59 +0200 Subject: [Live-devel] mpeg-2 transport stream Rate Message-ID: Hello, I would like to ask questions regarding mpeg-2 transport stream in live555. - Is the stream rate constant ? How is the rate determined: externally or internally by transport muxer ? - How does the mpeg-ts mux decide which input stream to deliver next from the inputs waiting ? - Is null packets used for keeping a constant rate ? - Is it possible to create multiple streams ? Thank you very much! Ran From CERLANDS at arinc.com Tue Jul 3 14:18:10 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Tue, 3 Jul 2012 21:18:10 +0000 Subject: [Live-devel] Regarding the build In-Reply-To: References: Message-ID: Example with a x64 OS: VS2010: c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ VS2008: c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ I btw use the short path (that you can see with dir /X) to avoid issue with space: c:\PROGRA~2\MICROS~2.0\VC /C From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of dushyanth Sent: Tuesday, July 03, 2012 10:04 AM To: live-devel at ns.live555.com Subject: Re: [Live-devel] Regarding the build In the instructions to build and run the libraries for windows, the second point says "If the 'tools' directory on your Windows machine is something other than "c:\Program Files\DevStudio\Vc", change the "TOOLS32 =" line in the file "win32config" " where can i expect to find this directory. Is it the tools folder in my visual studio package? Thanks. -- Dushyanth Subramanya University of Pennsylvania Class of 2012 School of Engineering & Applied Science MSE, MCIT www.seas.upenn.edu/~dushs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From CERLANDS at arinc.com Tue Jul 3 14:30:47 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Tue, 3 Jul 2012 21:30:47 +0000 Subject: [Live-devel] RTSP - Absolute Time Message-ID: After doing some testing with openRTSP and looking through the code it appears like "Absolute Time" is currently not supported for RTSP streams. I.e. I can't specify a specific time that the stream should seek to, e.g. Range: clock=20120629T070000.00Z, all according to paragraph 3.7 at http://www.ietf.org/rfc/rfc2326.txt. I see some remarks for "clock" (and "smtpe") in the code at RTSPCommon->parseRangeParam() which sort of confirms that this is still to be done. I'm curious if there is a reason that absolute time has been left out, i.e. are there problems implementing it, or is it just that people for some reason haven't been showing any interest in it? I find the seek functionality to be an essential part of RTSP, but it's kind of hard to implement anything with just the npt-time (Normal Play Time) to use. For most uses, like Video Management Systems that uses a circular buffer, the start is a moving target, i.e. seeking to 50 minutes might not take you to the same place in 10 minutes as it does now. Do you know of any reliable workarounds? Thanks! /Claes From finlayson at live555.com Tue Jul 3 15:04:21 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Jul 2012 15:04:21 -0700 Subject: [Live-devel] RTSP - Absolute Time In-Reply-To: References: Message-ID: <08A2F295-E1A1-4617-9AF8-46E66B4EEDBC@live555.com> > I'm curious if there is a reason that absolute time has been left out, i.e. are there problems implementing it, or is it just that people for some reason haven't been showing any interest in it? Until recently, there just hasn't been any interest in supporting seeking by 'absolute time'; instead, almost every application that wants to seek within a stream wants to seek using a relative time (from the start of the stream, or from its current position). However, you're the second person recently who has expressed interest in supporting this, so it's probably something that I'll add to the 'to do' list. (Supporting this might be nontrivial, though, because right now the code assumes - in lots of places - that only streams with a known duration can be 'seekable'.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.lc at vaelsys.com Wed Jul 4 00:16:47 2012 From: jesus.lc at vaelsys.com (=?ISO-8859-1?Q?Jes=FAs_Legan=E9s?=) Date: Wed, 4 Jul 2012 09:16:47 +0200 Subject: [Live-devel] Set ProxyServerMediaSession::fProxyRTSPClient as protected In-Reply-To: References: <57A1ECC3-87BC-4B23-A847-BB7C13D9EB6D@live555.com> Message-ID: > I hope this now allows you to do what you want with your subclasses... > It works like a charm... :-) Thank you! :-D -- Jes?s Legan?s Combarro Software developer at Vaelsys From saurabhg at godrej.com Thu Jul 5 01:11:41 2012 From: saurabhg at godrej.com (Saurabh Gandhi) Date: Thu, 5 Jul 2012 13:41:41 +0530 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server Message-ID: <001201cd5a85$d0a755b0$71f60110$@com> Hello everyone, I am using Live555 streaming media for an application which records and re-streams RTSP streams coming from IP camera. For that, I am using openRTSP for recording and live555 proxy server for re-streaming the camera stream. For a few of the cameras we are facing a strange issue where in the camera recording happens successfully, however the live555 proxy server is unable to generate a new stream for the same camera stream (there is no indication of failure in the verbose output dump, however the rtsp url generated by proxy server cannot be decoded by an rtsp client). Since I do not have any idea about the live555 proxy server details, I have been unable to get into this problem. I tried streaming the same camera stream using VLC and that works fine. What could be possibly wrong with this. I am here by attaching the verbose output for reference. E:\...\live\proxyServer>live555ProxyServer.exe -V rtsp://10.17.10.67/ch0_unicast_firststream LIVE555 Proxy Server (LIVE555 Streaming Media library version 2012.05.17) Opening connection to 10.17.10.67, port 554... RTSP stream, proxying the stream "rtsp://10.17.10.67/ch0_unicast_firststream" Play this stream using the URL "rtsp://10.17.1.150/proxyStream" (We use port 8000 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://10.17.10.67/ch0_unicast_firststream RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Accept: application/sdp Received 716 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, Jul 04 2012 10:55:19 GMT Content-Base: rtsp://10.17.10.67/ch0_unicast_firststream/ Content-Type: application/sdp Content-Length: 540 v=0 o=- 1341385393116860 1 IN IP4 10.17.10.67 s=Session of first stream i=First Codec Stream t=0 0 a=tool:LIVE555 Streaming Media v2007.08.03 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session of first stream a=x-qt-text-inf:First Codec Stream m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=5;config=000001B005000001B509000001000000012000847A98 28A02240A31F a=control:track1 m=metadata 0 RTP/AVP 97 c=IN IP4 0.0.0.0 a=rtpmap:97 METADATA/64000 a=control:track2 ProxyServerMediaSession["rtsp://10.17.10.67/ch0_unicast_firststream/"] added new "ProxyServerMediaSubsession" for RTP/video/MP4V-ES track ProxyServerMediaSession["rtsp://10.17.10.67/ch0_unicast_firststream/"] added new "ProxyServerMediaSubsession" for RTP/metadata/METADATA track Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 122 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, Jul 04 2012 10:55:56 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Opening connection to 10.17.10.67, port 554... ...remote connection opened Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 122 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, Jul 04 2012 10:56:48 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Opening connection to 10.17.10.67, port 554... ...remote connection opened Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 122 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, Jul 04 2012 10:57:43 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 6 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 122 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, Jul 04 2012 10:58:23 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 7 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 122 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 7 Date: Wed, Jul 04 2012 10:59:04 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 8 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) ProxyRTSPClient["rtsp://10.17.10.67/ch0_unicast_firststream/"]: lost connection to server ('errno': 10057). Resetting... Opening connection to 10.17.10.67, port 554... ...remote connection opened Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 9 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 122 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 9 Date: Wed, Jul 04 2012 11:00:29 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Opening connection to 10.17.10.67, port 554... ...remote connection opened Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 10 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 123 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 10 Date: Wed, Jul 04 2012 11:01:22 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 11 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 123 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 11 Date: Wed, Jul 04 2012 11:02:05 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 12 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 123 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 12 Date: Wed, Jul 04 2012 11:02:39 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 13 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 123 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 13 Date: Wed, Jul 04 2012 11:03:10 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0 CSeq: 14 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17) Received 123 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 14 Date: Wed, Jul 04 2012 11:03:46 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Regards, Saurabh Gandhi Disclaimer: This message (including any attachments) contains confidential information and is intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action based on the contents of this information is strictly prohibited. If you have received this email in error please notify mailadm at godrej.com. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Godrej & Boyce Mfg. Co. Ltd. group of companies. The recipient should check this email and any attachments for the presence of viruses. Godrej & Boyce Mfg. Co. Ltd. group of companies accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 5 01:25:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Jul 2012 01:25:54 -0700 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server In-Reply-To: <001201cd5a85$d0a755b0$71f60110$@com> References: <001201cd5a85$d0a755b0$71f60110$@com> Message-ID: <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> The proxy server appears to be running correctly, but - for some unknown reason - is not handling any requests from a 'front-end' client. To try to figure out what's going wrong, I suggest running "testRTSPClient rtsp://10.17.1.150/proxyStream" Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajax.chai at alcatel-lucent.com Thu Jul 5 04:41:40 2012 From: ajax.chai at alcatel-lucent.com (Chai, Zheng (Ajax)) Date: Thu, 5 Jul 2012 13:41:40 +0200 Subject: [Live-devel] live-devel Digest, Vol 105, Issue 4 In-Reply-To: References: Message-ID: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBB040D@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Ross, >> The problem is on step 2) & 3), when live555 received the FUs-A, it cannot delivery successfully to the H264VideoRTPSink if I use FUs-A. >Remember that - to receive H.264/RTP packets - you must use a "H264VideoRTPSource" object. If you are doing this, and you find that the "H264VideoRTPSource" object is not defragmenting the FU-A fragments >properly, then perhaps the incoming H.264/RTP are not properly formed - i.e., do not properly conform to the H.264 RTP payload format?? >Because you are not using our software to construct and stream the H.264/RTP packets towards our server, then we can't help you here; you're going to have to figure out for yourself why "H264VideoRTPSource" is >not behaving as expected. Sorry. (But Remember, You Have Complete Source Code.) I debugged the whole day, and I found the strange behavior of Live555 to receive the FU-As. Even I followed the following H264 Over RTP (RFC3984), Live555 still can not receive/parse them correctly. When I do the H264 video capture and fragmentation, I send as the RTP package as following order. 1) Send the SPS RTP package: {[12bytes - rtp header][NALU Header: 0x67 - 1 byte][8-bytes sps]}; -- note: my video source totally 9 bytes SPS. 2) Send the PPS RTP package: {[12bytes - rtp header][NALU Header: 0x68 - 1 byte][3-bytes pps]}; -- note: my video source totally 4 bytes PPS; Note: 1) & 2) will be sent on every Iframe is hitting. Then, if needn't package fragmentation (<1400) Send Single NAL units: {[12bytes - rtp header][NALU Header 0x65 or 0x61 - 1 byte][00 00 00 01 - 4bytes starter][NALU frame H264 data]}; Else If needs package fragmentation(>=1400) Send the FU-A RTP start package: {[12bytes- rtp header][0x7c - 1byte FU-A indicator][0x81 - 1byte FU-A header, S bit is set][00 00 00 01 - 4bytes starter][NALU frame H264 data]}; Then send the FU-A RTP middle package: {[12bytes- rtp header][0x7c - 1byte FU-A indicator][0x01 - 1byte FU-A header][NALU frame H264 data]}; Then send the RU-A RTP end package: {[12bytes- rtp header][0x7c - 1byte FU-A indicator][0x41 - 1byte FU-A header, E bit is set][NALU frame H264 data]}; I was confused that why Live555 can not parse above data. from my debugging, seems it can handle the FU-As and merge them togeter, but it can not handle the starter (00 00 00 01) and NALU type correctly. Please point me out if my data sending is not correct to meet Live555's requirements. Appreciate you help on this. Best Regards Ajax Chai -----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: Wednesday, July 04, 2012 6:04 AM To: live-devel at ns.live555.com Subject: live-devel Digest, Vol 105, Issue 4 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: About the H264 over RTP FA (Ross Finlayson) 2. Re: Regarding the build (dushyanth) 3. mpeg-2 transport stream Rate (Ran Shalit) 4. Re: Regarding the build (Erlandsson, Claes P (CERLANDS)) 5. RTSP - Absolute Time (Erlandsson, Claes P (CERLANDS)) 6. Re: RTSP - Absolute Time (Ross Finlayson) ---------------------------------------------------------------------- Message: 1 Date: Tue, 3 Jul 2012 02:12:47 -0700 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] About the H264 over RTP FA Message-ID: <489ABC76-6837-4E98-BC61-4119D4EC2C4F at live555.com> Content-Type: text/plain; charset="us-ascii" > The problem is on step 2) & 3), when live555 received the FUs-A, it cannot delivery successfully to the H264VideoRTPSink if I use FUs-A. Remember that - to receive H.264/RTP packets - you must use a "H264VideoRTPSource" object. If you are doing this, and you find that the "H264VideoRTPSource" object is not defragmenting the FU-A fragments properly, then perhaps the incoming H.264/RTP are not properly formed - i.e., do not properly conform to the H.264 RTP payload format?? Because you are not using our software to construct and stream the H.264/RTP packets towards our server, then we can't help you here; you're going to have to figure out for yourself why "H264VideoRTPSource" is not behaving as expected. Sorry. (But Remember, You Have Complete Source Code.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 3 Jul 2012 11:04:02 -0400 From: dushyanth To: live-devel at ns.live555.com Subject: Re: [Live-devel] Regarding the build Message-ID: Content-Type: text/plain; charset="iso-8859-1" In the instructions to build and run the libraries for windows, the second point says "If the 'tools' directory on your Windows machine is something *other than*"c:\Program Files\DevStudio\Vc", change the "TOOLS32 =" line in the file "win32config" " where can i expect to find this directory. Is it the tools folder in my visual studio package? Thanks. -- Dushyanth Subramanya University of Pennsylvania Class of 2012 School of Engineering & Applied Science MSE, MCIT www.seas.upenn.edu/~dushs -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 3 Jul 2012 22:20:59 +0200 From: Ran Shalit To: live-devel at ns.live555.com Subject: [Live-devel] mpeg-2 transport stream Rate Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hello, I would like to ask questions regarding mpeg-2 transport stream in live555. - Is the stream rate constant ? How is the rate determined: externally or internally by transport muxer ? - How does the mpeg-ts mux decide which input stream to deliver next from the inputs waiting ? - Is null packets used for keeping a constant rate ? - Is it possible to create multiple streams ? Thank you very much! Ran ------------------------------ Message: 4 Date: Tue, 3 Jul 2012 21:18:10 +0000 From: "Erlandsson, Claes P (CERLANDS)" To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Regarding the build Message-ID: Content-Type: text/plain; charset="us-ascii" Example with a x64 OS: VS2010: c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ VS2008: c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ I btw use the short path (that you can see with dir /X) to avoid issue with space: c:\PROGRA~2\MICROS~2.0\VC /C From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of dushyanth Sent: Tuesday, July 03, 2012 10:04 AM To: live-devel at ns.live555.com Subject: Re: [Live-devel] Regarding the build In the instructions to build and run the libraries for windows, the second point says "If the 'tools' directory on your Windows machine is something other than "c:\Program Files\DevStudio\Vc", change the "TOOLS32 =" line in the file "win32config" " where can i expect to find this directory. Is it the tools folder in my visual studio package? Thanks. -- Dushyanth Subramanya University of Pennsylvania Class of 2012 School of Engineering & Applied Science MSE, MCIT www.seas.upenn.edu/~dushs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: ------------------------------ Message: 5 Date: Tue, 3 Jul 2012 21:30:47 +0000 From: "Erlandsson, Claes P (CERLANDS)" To: "live-devel at lists.live555.com" Subject: [Live-devel] RTSP - Absolute Time Message-ID: Content-Type: text/plain; charset="us-ascii" After doing some testing with openRTSP and looking through the code it appears like "Absolute Time" is currently not supported for RTSP streams. I.e. I can't specify a specific time that the stream should seek to, e.g. Range: clock=20120629T070000.00Z, all according to paragraph 3.7 at http://www.ietf.org/rfc/rfc2326.txt. I see some remarks for "clock" (and "smtpe") in the code at RTSPCommon->parseRangeParam() which sort of confirms that this is still to be done. I'm curious if there is a reason that absolute time has been left out, i.e. are there problems implementing it, or is it just that people for some reason haven't been showing any interest in it? I find the seek functionality to be an essential part of RTSP, but it's kind of hard to implement anything with just the npt-time (Normal Play Time) to use. For most uses, like Video Management Systems that uses a circular buffer, the start is a moving target, i.e. seeking to 50 minutes might not take you to the same place in 10 minutes as it does now. Do you know of any reliable workarounds? Thanks! /Claes ------------------------------ Message: 6 Date: Tue, 3 Jul 2012 15:04:21 -0700 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTSP - Absolute Time Message-ID: <08A2F295-E1A1-4617-9AF8-46E66B4EEDBC at live555.com> Content-Type: text/plain; charset="us-ascii" > I'm curious if there is a reason that absolute time has been left out, i.e. are there problems implementing it, or is it just that people for some reason haven't been showing any interest in it? Until recently, there just hasn't been any interest in supporting seeking by 'absolute time'; instead, almost every application that wants to seek within a stream wants to seek using a relative time (from the start of the stream, or from its current position). However, you're the second person recently who has expressed interest in supporting this, so it's probably something that I'll add to the 'to do' list. (Supporting this might be nontrivial, though, because right now the code assumes - in lots of places - that only streams with a known duration can be 'seekable'.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 105, Issue 4 ****************************************** From manishkr at ee.iisc.ernet.in Thu Jul 5 03:34:52 2012 From: manishkr at ee.iisc.ernet.in (manishkr at ee.iisc.ernet.in) Date: Thu, 5 Jul 2012 16:04:52 +0530 (IST) Subject: [Live-devel] [Fwd: installation and retrieval of h.264 bit streams from ip cameras]]] Message-ID: ---------------------------- Original Message ---------------------------- Subject: installation and retrieval of h.264 bit streams from ip cameras]] From: manishkr at ee.iisc.ernet.in Date: Thu, July 5, 2012 4:01 pm To: live-devel at lists.live555.com -------------------------------------------------------------------------- i have installed different ip cameras in the network which outputs h.264 format bit stream. i want to store the streams using live555 Streaming media. i am working on windows 7 and using visual studio 7. i am not able to install the required files. i downloaded the source code from the web site and then unpacked it. i also generated the make files in different foledrs but there after i am not able to proceed. it is showing errors. kindly help me to install the "live555 Streaming media" on windows 7 using visual studio 10.0. i am new to live555, so kindly guide me to collect the information (h.264) using this package. thanking you. manish kumar cvai lab iisc bangalore india -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From finlayson at live555.com Thu Jul 5 07:51:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Jul 2012 07:51:24 -0700 Subject: [Live-devel] About the H264 over RTP FA In-Reply-To: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBB040D@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> References: <79D8B3BF3F11934E8EE32BBAD9F77B9C615FBB040D@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Message-ID: <5CFFE20A-E8CB-4600-BA05-94059E5B082C@live555.com> First of all: Because you have - in two successive messages - violated basic email 'netiquette' by not trimming the original text from your response (and also by not changing the "Subject:" line from "Live-devel] live-devel Digest ...", all future postings from you will be moderated! > I was confused that why Live555 can not parse above data. from my debugging, seems it can handle the FU-As and merge them togeter, but it can not handle the starter (00 00 00 01) and NALU type correctly. There's your problem right there. HAL units - when packed into RTP packets - MUST NOT include the "00 00 00 01" start codes. Section 1.3 of RFC 3984 describes the first byte of each NAL unit that is packed into a RTP packet. (Of course, if you had used our software to *send* your H.264/RTP packets - rather than just to receive them - then you would not have had these problems...) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From myselfasunder at gmail.com Thu Jul 5 00:12:41 2012 From: myselfasunder at gmail.com (Dustin Oprea) Date: Thu, 5 Jul 2012 03:12:41 -0400 Subject: [Live-devel] Stream control issues Message-ID: The binary worked great under Windows-- I was able to load test an MPEG1 (non-ES) video and click to the middle of the video without a problem. I built the source-code under Linux on both a remote server and Ubuntu under a local VM, and the same video will load, but will: 1) NOT report it's duration properly. 2) NOT allow the user to jump ahead. I am using VLC as the client. Does anyone have any advice? I can't start the project until I can figure this out. Dustin Oprea -------------- next part -------------- An HTML attachment was scrubbed... URL: From 6253500 at 163.com Thu Jul 5 03:56:49 2012 From: 6253500 at 163.com (=?GBK?B?stzF9LfJ?=) Date: Thu, 5 Jul 2012 18:56:49 +0800 (CST) Subject: [Live-devel] how proxyServer get buffer? Message-ID: <6ea74128.d89a.13856c900f7.Coremail.6253500@163.com> could you give me some advice ? I'm hoping to get the buffer from proxyserver,but I donn't know how to get. when broadcasting real-time video streaming, in which step that proxyserver can get video streaming buffer ? Could you give me some advice ? I'm hoping to get the buffer. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiran.thakkar at gmail.com Thu Jul 5 05:29:46 2012 From: kiran.thakkar at gmail.com (Kiran P. Thakkar) Date: Thu, 5 Jul 2012 17:59:46 +0530 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server In-Reply-To: <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> References: <001201cd5a85$d0a755b0$71f60110$@com> <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> Message-ID: Hello Ross,**** I and Saurabh are working on same project. ** ** We tried analyzing into what is happening by using the testRTSPClient as suggested by you and here is the verbose dump of the testRTSPClient:**** ** ** Opening connection to 10.17.1.111, port 8554...**** ...remote connection opened**** Sending request: DESCRIBE rtsp://10.17.1.111:8554/proxyStream RTSP/1.0**** CSeq: 2**** User-Agent: D:\KiranThakkar\VMS\live555-latest-windows\live\testProgs\TestProgra**** ms___Win32_Debug\TestPrograms.exe (LIVE555 Streaming Media v2012.06.26)**** Accept: application/sdp**** ** ** ** ** Received 101 new bytes of response data.**** Received a complete DESCRIBE response:**** RTSP/1.0 404 File Not Found, Or In Incorrect Format**** CSeq: 2**** Date: Thu, Jul 05 2012 09:23:54 GMT**** ** ** ** ** [URL:"rtsp://10.17.1.111:8554/proxyStream"]: Failed to get a SDP description: 40**** 4 File Not Found, Or In Incorrect Format**** [URL:"rtsp://10.17.1.111:8554/proxyStream"]: Closing the stream.**** Press any key to continue**** ** ** It seems that the live555 proxy server is unable to provide a response to the DESCRIBE request sent from the client (testRTSPClient). What could be the reason for this. I am hereby attaching the corresponding live555 proxy server verbose dump as well for reference.**** ** ** LIVE555 Proxy Server**** (LIVE555 Streaming Media library version 2012.06.26)**** ** ** Opening connection to 10.17.10.67, port 554...**** RTSP stream, proxying the stream "rtsp://10.17.10.67/ch0_unicast_firststream "**** Play this stream using the URL "rtsp://10.17.1.111:8554/proxyStream" **** ** ** (We use port 80 for optional RTSP-over-HTTP tunneling.)**** ...remote connection opened**** Sending request: DESCRIBE rtsp://10.17.10.67/ch0_unicast_firststream RTSP/1.0**** CSeq: 2**** User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)**** Accept: application/sdp**** ** ** ** ** Received 718 new bytes of response data.**** Received a complete DESCRIBE response:**** RTSP/1.0 200 OK**** CSeq: 2**** Date: Thu, Jul 05 2012 09:19:08 GMT**** Content-Base: rtsp://10.17.10.67/ch0_unicast_firststream/**** Content-Type: application/sdp**** Content-Length: 542**** ** ** v=0**** o=- 1341403933373938 1 IN IP4 10.17.10.67**** s=Session of first stream**** i=First Codec Stream**** t=0 0**** a=tool:LIVE555 Streaming Media v2007.08.03**** a=type:broadcast**** a=control:***** a=range:npt=0-**** a=x-qt-text-nam:Session of first stream**** a=x-qt-text-inf:First Codec Stream**** m=video 0 RTP/AVP 96**** c=IN IP4 0.0.0.0**** a=rtpmap:96 H264/90000**** a=fmtp:96 packetization-mode=1;profile-level-id=428028;sprop-parameter-sets=Z0KA**** KNoC0EkQ,aM48gA==**** a=control:track1**** m=metadata 0 RTP/AVP 97**** c=IN IP4 0.0.0.0**** a=rtpmap:97 METADATA/64000**** a=control:track2**** ** ** ProxyServerMediaSession["rtsp://10.17.10.67/ch0_unicast_firststream/"] added new**** "ProxyServerMediaSubsession" for RTP/video/H264 track**** ProxyServerMediaSession["rtsp://10.17.10.67/ch0_unicast_firststream/"] added new**** "ProxyServerMediaSubsession" for RTP/metadata/METADATA track**** Opening connection to 10.17.10.67, port 554...**** ...remote connection opened**** Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0**** CSeq: 3**** User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)**** ** ** ** ** Received 122 new bytes of response data.**** Received a complete OPTIONS response:**** RTSP/1.0 200 OK**** CSeq: 3**** Date: Thu, Jul 05 2012 09:20:09 GMT**** Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE**** ** ** ** ** ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0)**** Initiated: ProxyServerMediaSubsession["H264"]**** ProxyServerMediaSubsession["H264"]::createNewRTPSink()**** ProxyServerMediaSubsession["H264"]::closeStreamSource()**** ProxyServerMediaSubsession["METADATA"]::createNewStreamSource(session id 0)* *** Initiated: ProxyServerMediaSubsession["METADATA"]**** Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0**** CSeq: 4**** User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)**** ** ** ** ** Received 122 new bytes of response data.**** Received a complete OPTIONS response:**** RTSP/1.0 200 OK**** CSeq: 4**** Date: Thu, Jul 05 2012 09:20:42 GMT**** Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE**** ** ** ** ** Opening connection to 10.17.10.67, port 554...**** ...remote connection opened**** Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0**** CSeq: 5**** User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)**** ** ** ** ** Received 122 new bytes of response data.**** Received a complete OPTIONS response:**** RTSP/1.0 200 OK**** CSeq: 5**** Date: Thu, Jul 05 2012 09:21:29 GMT**** Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE**** ** ** ** ** ProxyServerMediaSubsession["METADATA"]::createNewStreamSource(session id 0)* *** Initiated: ProxyServerMediaSubsession["METADATA"]**** Opening connection to 10.17.10.67, port 554...**** ...remote connection opened**** Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0**** CSeq: 6**** User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)**** ** ** ** ** Received 122 new bytes of response data.**** Received a complete OPTIONS response:**** RTSP/1.0 200 OK**** CSeq: 6**** Date: Thu, Jul 05 2012 09:22:29 GMT**** Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE**** ** ** ** ** ProxyServerMediaSubsession["METADATA"]::createNewStreamSource(session id 0)* *** Initiated: ProxyServerMediaSubsession["METADATA"]**** ** ** Regards,**** Kiran On Thu, Jul 5, 2012 at 1:55 PM, Ross Finlayson wrote: > The proxy server appears to be running correctly, but - for some unknown > reason - is not handling any requests from a 'front-end' client. > > To try to figure out what's going wrong, I suggest running "testRTSPClient > rtsp://10.17.1.150/proxyStream" > > > 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 Jul 5 08:45:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Jul 2012 08:45:59 -0700 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server In-Reply-To: References: <001201cd5a85$d0a755b0$71f60110$@com> <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> Message-ID: This is very strange. I don't understand why the proxy server is responding "404 File Not Found..." to requests by the client. To try to solve this, I suggest doing the following: 1/ Edit "liveMedia/RTSPServer.cpp", and add the line #define DEBUG 1 to the start of the file. 2/ Recompile the "liveMedia" library. 3/ In the "proxyServer" library, re-make the "live555ProxyServer" binary. 4/ Run "live555ProxyServer -V " once again, and try connecting to it from the client. Send us the debugging output from the proxy server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 5 08:50:13 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Jul 2012 08:50:13 -0700 Subject: [Live-devel] Stream control issues In-Reply-To: References: Message-ID: <8451F2D6-05E2-43DB-BDBE-770859362952@live555.com> > The binary worked great under Windows-- I was able to load test an MPEG1 (non-ES) video and click to the middle of the video without a problem. I built the source-code under Linux on both a remote server and Ubuntu under a local VM, and the same video will load, but will: > > 1) NOT report it's duration properly. > 2) NOT allow the user to jump ahead. > > I am using VLC as the client. Does anyone have any advice? It's difficult - if not impossible - to answer questions like this unless we can see the MPEG Program Stream (I presume) file that you're using for testing. Please put it on a publicly-accessible web server, and send us the URL, so we can download it and test it for ourselves. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiran.thakkar at gmail.com Thu Jul 5 22:58:23 2012 From: kiran.thakkar at gmail.com (Kiran P. Thakkar) Date: Fri, 6 Jul 2012 11:28:23 +0530 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server In-Reply-To: References: <001201cd5a85$d0a755b0$71f60110$@com> <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> Message-ID: Dear Ross, Thanks for your response. I have dump debug info which you have suggested. Please find log below. ************************ LOG INFO-START****************************************************************************************************************************** *LIVE555 Proxy Server* * (LIVE555 Streaming Media library version 2012.06.26)* * * *Opening connection to 10.17.10.56, port 554...* *RTSP stream, proxying the stream "rtsp:// 10.17.10.56/ch0_unicast_firststream"* * Play this stream using the URL "rtsp://10.17.1.111:8554/proxyStream "* * * *(We use port 80 for optional RTSP-over-HTTP tunneling.)* *...remote connection opened* *Sending request: DESCRIBE rtsp://10.17.10.56/ch0_unicast_firststreamRTSP/1.0 * *CSeq: 2* *User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)* *Accept: application/sdp* * * * * *Received 716 new bytes of response data.* *Received a complete DESCRIBE response:* *RTSP/1.0 200 OK* *CSeq: 2* *Date: Fri, Jul 06 2012 11:05:59 GMT* *Content-Base: rtsp://10.17.10.56/ch0_unicast_firststream/* *Content-Type: application/sdp* *Content-Length: 540* * * *v=0* *o=- 1341318888742256 1 IN IP4 10.17.10.56* *s=Session of first stream* *i=First Codec Stream* *t=0 0* *a=tool:LIVE555 Streaming Media v2007.08.03* *a=type:broadcast* *a=control:** *a=range:npt=0-* *a=x-qt-text-nam:Session of first stream* *a=x-qt-text-inf:First Codec Stream* *m=video 0 RTP/AVP 96* *c=IN IP4 0.0.0.0* *a=rtpmap:96 MP4V-ES/90000* *a=fmtp:96 profile-level-id=5;config=000001B005000001B509000001000000012000847A98* *28A02240A31F* *a=control:track1* *m=metadata 0 RTP/AVP 97* *c=IN IP4 0.0.0.0* *a=rtpmap:97 METADATA/64000* *a=control:track2* * * *ProxyServerMediaSession["rtsp://10.17.10.56/ch0_unicast_firststream/"] added new* * "ProxyServerMediaSubsession" for RTP/video/MP4V-ES track* *ProxyServerMediaSession["rtsp://10.17.10.56/ch0_unicast_firststream/"] added new* * "ProxyServerMediaSubsession" for RTP/metadata/METADATA track* *Sending request: OPTIONS rtsp://10.17.10.56/ch0_unicast_firststream/RTSP/1.0 * *CSeq: 3* *User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)* * * * * *Received 122 new bytes of response data.* *Received a complete OPTIONS response:* *RTSP/1.0 200 OK* *CSeq: 3* *Date: Fri, Jul 06 2012 11:06:33 GMT* *Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE* * * * * *accept()ed connection from 10.17.1.111* *Liveness indication from client at 10.17.1.111* *Liveness indication from client at 10.17.1.111* *RTSPClientSession[02060068]::handleRequestBytes() read 161 new bytes:DESCRIBE rt* *sp://10.17.1.111:8554/proxyStream RTSP/1.0* *CSeq: 2* *User-Agent: testRTSPClient.exe (LIVE555 Streaming Media v2012.05.11)* *Accept: application/sdp* * * * * *parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "* *", urlSuffix "proxyStream", CSeq "2", Content-Length 0, with 0 bytes following t* *he message.* *ProxyServerMediaSubsession["MP4V-ES"]::createNewStreamSource(session id 0)* * Initiated: ProxyServerMediaSubsession["MP4V-ES"]* *ProxyServerMediaSubsession["MP4V-ES"]::createNewRTPSink()* *ProxyServerMediaSubsession["MP4V-ES"]::closeStreamSource()* *ProxyServerMediaSubsession["METADATA"]::createNewStreamSource(session id 0) * * Initiated: ProxyServerMediaSubsession["METADATA"]* *sending response: RTSP/1.0 404 File Not Found, Or In Incorrect Format* *CSeq: 2* *Date: Fri, Jul 06 2012 05:38:16 GMT* * * *Liveness indication from client at 10.17.1.111* *RTSPClientSession[02060068]::handleRequestBytes() read 0 new bytes (of 10000); t* *erminating connection!* *Sending request: OPTIONS rtsp://10.17.10.56/ch0_unicast_firststream/RTSP/1.0 * *CSeq: 4* *User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)* * * * * *Received 122 new bytes of response data.* *Received a complete OPTIONS response:* *RTSP/1.0 200 OK* *CSeq: 4* *Date: Fri, Jul 06 2012 11:07:10 GMT* *Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE* * * * * *Opening connection to 10.17.10.56, port 554...* *...remote connection opened* *Sending request: OPTIONS rtsp://10.17.10.56/ch0_unicast_firststream/RTSP/1.0 * *CSeq: 5* *User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)* * * * * *Received 122 new bytes of response data.* *Received a complete OPTIONS response:* *RTSP/1.0 200 OK* *CSeq: 5* *Date: Fri, Jul 06 2012 11:08:09 GMT* *Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE* *******************************LOG INFO END****************************************************************************************** I have verified Debug info from RTSPServer.cpp is effected It is keep printing for other working camera( It prints *Liveness indication from client at 10.17.1.111..)* In current log also once its prints* **Liveness indication from client at 10.17.1.111.* * * and in testRTSPClient is giving following log which is similar to previously * * * **************************LOG***************************************************** * * Opening connection to 10.17.1.111, port 8554... ...remote connection opened Sending request: DESCRIBE rtsp://10.17.1.111:8554/proxyStream RTSP/1.0 CSeq: 2 User-Agent: testRTSPClient.exe (LIVE555 Streaming Media v2012.05.11) Accept: application/sdp Received 101 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 404 File Not Found, Or In Incorrect Format CSeq: 2 Date: Fri, Jul 06 2012 05:53:08 GMT [URL:"rtsp://10.17.1.111:8554/proxyStream"]: Failed to get a SDP description: 40 4 File Not Found, Or In Incorrect Format [URL:"rtsp://10.17.1.111:8554/proxyStream"]: Closing the stream. * * ***************************LOG************************************************************************************************************ * Please help Regards Kiran On Thu, Jul 5, 2012 at 9:15 PM, Ross Finlayson wrote: > This is very strange. I don't understand why the proxy server is > responding "404 File Not Found..." to requests by the client. > > To try to solve this, I suggest doing the following: > 1/ Edit "liveMedia/RTSPServer.cpp", and add the line > > #define DEBUG 1 > > to the start of the file. > 2/ Recompile the "liveMedia" library. > 3/ In the "proxyServer" library, re-make the "live555ProxyServer" binary. > 4/ Run "live555ProxyServer -V " once again, and try > connecting to it from the client. Send us the debugging output from the > proxy server. > > > 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 Jul 6 06:18:12 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 6 Jul 2012 06:18:12 -0700 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server In-Reply-To: References: <001201cd5a85$d0a755b0$71f60110$@com> <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> Message-ID: OK, I figured out the problem - it was caused by the nonstandard 'metadata' track in the back-end stream. Because this track is non-standard, we can't proxy it, but that should not have prevented the other, standard 'video' track from being proxied. I've now installed a new version "2012.07.06" of the "LIVE555 Streaming Media" software that should fix this problem. Now, your front-end client should be able to receive the 'video' track OK. Thanks for bringing this issue to our attention. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjh431 at gmail.com Thu Jul 5 23:46:06 2012 From: sjh431 at gmail.com (jhseo) Date: Fri, 6 Jul 2012 15:46:06 +0900 Subject: [Live-devel] Question about MPEG2TransportStreamMultiplexor Class Message-ID: <051a01cd5b43$06841bb0$138c5310$@gmail.com> Hi. I'm using LIVE555 Proxyserver. Can I multiplexing RTSP/RTP stream to mpeg2-ts using MPEG2TransportStreamMultiplexor class in LIVE555? The stream is received from back-end LIVE555 stream server. (video stream: H.264, audio stream: AAC) Thanks for your interest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ketangholap1990 at gmail.com Thu Jul 5 23:57:59 2012 From: ketangholap1990 at gmail.com (Ketan Gholap) Date: Fri, 6 Jul 2012 12:27:59 +0530 Subject: [Live-devel] RTSPServer.Error:The total received frame size exceeds the client's buffer size (40).1276 bytes of trailing data will be dropped Message-ID: hello Sir! I have made an application using live media 555 library. In this application I'm receiving video stream from my live media streamer application. Which in turns get stream from a dvd player. In my server application I'm creating rtsp server in my main program. And in same program I'm handling messages from anther client application which sends me START_STREAM and STOP_STREAM messages. As per client applications messages my server application creates a session to receive stream from streamer application and also to send same stream to client application. For first time START and STOP_STREAM works fine but when client sends START_STREAM next time, session is created by my server application but stream is not received by client application. My application shows following messages on screen. MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (40). 1276 bytes of trailing data will be dropped! sendRTPOverTCP: 1328 bytes over channel 0 (socket 932) sendRTPOverTCP: completed MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (19). 1297 bytes of trailing data will be dropped! when I go though MultiFramedRTPSource::doGetNextFrame1() function in MultiFramedRTPSource.cpp file I come to know that in this function "fNumTruncatedBytes" variable holds Truncated Bytes and comes into feature Second time when creating session. I dont know how to handle this error. Can anybody help? Code is given below. int StartRtspServer() { // Begin by setting up our usage environment: TaskScheduler* scheduler = BasicTaskScheduler::createNew(); env = BasicUsageEnvironment::createNew(*scheduler); UserAuthenticationDatabase* authDB = NULL; #ifdef ACCESS_CONTROL // To implement client access control to the RTSP server, do the following: authDB = new UserAuthenticationDatabase; authDB->addUserRecord("username1", "password1"); // replace these with real strings // Repeat the above with each , that you wish to allow // access to the server. #endif // Create the RTSP server: wLog->WriteInfoLog("Creating RTSP server.."); *env << "Creating RTSP server.."<<"\n."; portNumBits rtspServerPortNum = 554; rtspServer = RTSPServer::createNew(*env,rtspServerPortNum, authDB); if (rtspServer == NULL) { *env << "Failed to create RTSP server: " <getResultMsg()<<"\n"; return 0; } else { *env << "Created RTSP server.."<<"\n."; } } { case START_STREAM: Th1 = CreateThread(NULL,0, (LPTHREAD_START_ROUTINE)StartStreamingThread,0, 0, &Tid1); if(Th1 == NULL) { cout<<"Error while creating MessageReplyThread .\n"; } Sleep(1000); break; case STOP_STREAM: if( Th1) { // Terminate rtsp server thread cout<<"\nRemoving Server Media Session\n"; rtspServer->removeServerMediaSession(sms); sms=NULL; cout<<"\nClosing live media server Thread\n"; BOOL bVal =TerminateThread(Th1, 0); if ( bVal ) { cout<<"\nClosing thread handle..\n"; CloseHandle(ThreadHandle[0]); } Th1 = NULL; } Sleep(2000); break; } DWORD WINAPI StartStreamingThread(void) { *env <<"Entering in StartStreamingThread()\n"; char const* streamName = "stream1"; char const* inputAddressStr = MulticastIp; portNumBits const inputPortNum = StreamerPort; Boolean const inputStreamIsRawUDP = False; sms = ServerMediaSession::createNew(*env, streamName, streamName,descriptionString); sms->addSubsession(MPEG2TransportUDPServerMediaSubsession::createNew(*env, inputAddressStr, inputPortNum, inputStreamIsRawUDP)); rtspServer->addServerMediaSession(sms); char* url = rtspServer->rtspURL(sms); *env << "\n\"" << streamName << "\" stream, from a UDP Transport Stream input source \n\t("; if (inputAddressStr != NULL) { *env << "IP multicast address " << inputAddressStr << ","; } else { *env << "unicast;"; } *env << " port " << inputPortNum << ")\n"; *env << "Play this stream using the URL \"" << url << "\"\n"; delete[] url; if (rtspServer->setUpTunnelingOverHTTP(TunnelingPort) || rtspServer->setUpTunnelingOverHTTP(TunnelingPort) || rtspServer->setUpTunnelingOverHTTP(TunnelingPort)) { *env << "\n(We use port " << rtspServer->httpServerPortNum() << " for optional RTSP-over-HTTP tunneling.)\n"; } else { *env << "\n(RTSP-over-HTTP tunneling is not available.)\n"; } env->taskScheduler().doEventLoop(); // does not return return 0; // only to prevent compiler warning } -------------- next part -------------- An HTML attachment was scrubbed... URL: From reply2010 at yeah.net Fri Jul 6 08:30:05 2012 From: reply2010 at yeah.net (reply2010) Date: Fri, 6 Jul 2012 23:30:05 +0800 (CST) Subject: [Live-devel] about DeviceSource for multi channel encoder Message-ID: hi,experts i modify DeviceSource.cpp to stream a live encoder,but i find triggerEvent could not trigger deliverFrame0 function which is registered by eventTriggerId = env.taskScheduler().createEventTrigger(deliverFrame0); what is wrong with me? because my encoder has multi channel,i have to modify static variable EventTriggerId to non-static here is my code //*********************************************************** #include "DeviceSource.hh" #include // for "gettimeofday()" DeviceSource* DeviceSource::createNew(UsageEnvironment& env /*, DeviceParameters params*/) { return new DeviceSource(env/*, params*/); } //for non-static eventtriggerid //EventTriggerId DeviceSource::eventTriggerId = 0; //unsigned DeviceSource::referenceCount = 0; DeviceSource::DeviceSource(UsageEnvironment& env/*, DeviceParameters params*/) : FramedSource(env)/*, fParams(params)*/ { //**************************************** /* if (referenceCount == 0) { // Any global initialization of the device would be done here: //%%% TO BE WRITTEN %%% } ++referenceCount; */ //*********************************** // Any instance-specific initialization of the device would be done here: //%%% TO BE WRITTEN %%% // We arrange here for our "deliverFrame" member function to be called // whenever the next frame of data becomes available from the device. // // If the device can be accessed as a readable socket, then one easy way to do this is using a call to // envir().taskScheduler().turnOnBackgroundReadHandling( ... ) // (See examples of this call in the "liveMedia" directory.) // // If, however, the device *cannot* be accessed as a readable socket, then instead we can implement it using 'event triggers': // Create an 'event trigger' for this device (if it hasn't already been done): if (eventTriggerId == 0) { eventTriggerId = env.taskScheduler().createEventTrigger(deliverFrame0); } } DeviceSource::~DeviceSource() { // Any instance-specific 'destruction' (i.e., resetting) of the device would be done here: //%%% TO BE WRITTEN %%% //***************************** /*--referenceCount; if (referenceCount == 0) {*/ // Any global 'destruction' (i.e., resetting) of the device would be done here: //%%% TO BE WRITTEN %%% // Reclaim our 'event trigger' envir().taskScheduler().deleteEventTrigger(eventTriggerId); eventTriggerId = 0; //************************************* } } void DeviceSource::doGetNextFrame() { } void DeviceSource::deliverFrame0(void* clientData) { ((DeviceSource*)clientData)->deliverFrame(); return; } void DeviceSource::deliverFrame() { // This function is called when new frame data is available from the device. // We deliver this data by copying it to the 'downstream' object, using the following parameters (class members): // 'in' parameters (these should *not* be modified by this function): // fTo: The frame data is copied to this address. // (Note that the variable "fTo" is *not* modified. Instead, // the frame data is copied to the address pointed to by "fTo".) // fMaxSize: This is the maximum number of bytes that can be copied // (If the actual frame is larger than this, then it should // be truncated, and "fNumTruncatedBytes" set accordingly.) // 'out' parameters (these are modified by this function): // fFrameSize: Should be set to the delivered frame size (<= fMaxSize). // fNumTruncatedBytes: Should be set iff the delivered frame would have been // bigger than "fMaxSize", in which case it's set to the number of bytes // that have been omitted. // fPresentationTime: Should be set to the frame's presentation time // (seconds, microseconds). This time must be aligned with 'wall-clock time' - i.e., the time that you would get // by calling "gettimeofday()". // fDurationInMicroseconds: Should be set to the frame's duration, if known. // If, however, the device is a 'live source' (e.g., encoded from a camera or microphone), then we probably don't need // to set this variable, because - in this case - data will never arrive 'early'. // Note the code below. //*************************************************** if (!isCurrentlyAwaitingData()) {return;} // we're not ready for the data yet // Deliver the data here: if (newFrameSize > fMaxSize) { fFrameSize = fMaxSize; fNumTruncatedBytes = newFrameSize - fMaxSize; } else { fFrameSize = newFrameSize; } //gettimeofday(&fPresentationTime, NULL); // If you have a more accurate time - e.g., from an encoder - then use that instead. // If the device is *not* a 'live source' (e.g., it comes instead from a file or buffer), then set "fDurationInMicroseconds" here. memmove(fTo, newFrameDataStart, fFrameSize); requestData = true; // After delivering the data, inform the reader that it is now available: FramedSource::afterGetting(this); //*************************************************** } void DeviceSource::signalNewFrameData(UsageEnvironment* ourenv,DeviceSource* ourDevice) { //TaskScheduler ourScheduler ; //ourScheduler = env->taskScheduler(); //%%% TO BE WRITTEN %%% //DeviceSource* ourDevice = NULL; //%%% TO BE WRITTEN %%% //if (ourScheduler != NULL) { // sanity check ourenv->taskScheduler().triggerEvent(ourDevice->eventTriggerId, ourDevice); //} } here is DeviceSource.hh /********** This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. (See .) This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA **********/ // "liveMedia" // Copyright (c) 1996-2011 Live Networks, Inc. All rights reserved. // A template for a MediaSource encapsulating an audio/video input device // // NOTE: Sections of this code labeled "%%% TO BE WRITTEN %%%" are incomplete, and needto be written by the programmer // (depending on the features of the particulardevice). // C++ header #ifndef _DEVICE_SOURCE_HH #define _DEVICE_SOURCE_HH #ifndef _FRAMED_SOURCE_HH #include "FramedSource.hh" #endif // The following class can be used to define specific encoder parameters /*class DeviceParameters { //%%% TO BE WRITTEN %%% };*/ class DeviceSource: public FramedSource { public: static DeviceSource* createNew(UsageEnvironment& env /*, DeviceParameters params*/); public: //static EventTriggerId eventTriggerId; EventTriggerId eventTriggerId; //here change static into non-static protected: DeviceSource(UsageEnvironment& env /*, DeviceParameters params*/); // called only by createNew(), or by subclass constructors virtual ~DeviceSource(); private: // redefined virtual functions: virtual void doGetNextFrame(); private: static void deliverFrame0(void* clientData); public: void signalNewFrameData(UsageEnvironment* env,DeviceSource* ourDevice);//new func added by me public: void deliverFrame(); private: //static unsigned referenceCount; // used to count how many instances of this class currently exist //DeviceParameters fParams; public: bool requestData; public: u_int8_t* newFrameDataStart; unsigned newFrameSize; }; #endif at last,here is my main code part note that DVRChSource[i]'s type is DeviceSource * ...... if(DVRChSource[i]->requestData){ DVRChSource[i]->newFrameDataStart=(u_int8_t*)ChannelBuffer[i]; DVRChSource[i]->newFrameSize=ChannelBufferSize[i]; DVRChSource[i]->requestData=false; //env->taskScheduler().triggerEvent(DVRChSource[i]->eventTriggerId, DVRChSource[i]); DVRChSource[i]->signalNewFrameData(env,DVRChSource[i]); } ...... i debug and trace these code,i find deliverFrame0 could not be triggered after ourenv->taskScheduler().triggerEvent(ourDevice->eventTriggerId, ourDevice); executed. any light or any DeviceSource sample would be appreciated.thanks a lot. jounin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abmadaan at yahoo.com Fri Jul 6 13:05:38 2012 From: abmadaan at yahoo.com (Abhishek Madaan) Date: Fri, 6 Jul 2012 13:05:38 -0700 (PDT) Subject: [Live-devel] H.264 OpenRTSP Message-ID: <1341605138.38090.YahooMailNeo@web114515.mail.gq1.yahoo.com> Hi, ????? I have couple of questions: 1)? When I am running OpenRTSP to play H.264 RTSP stream coming from a camera, it creates video-H264-1 file. What type of file is that? I tried to run this file in vlc player but it doesn't run at all. ? 2)?I want to take the H.264 streaming using live555 library and feed to ffmpeg library so that it decode the h.264 frame. I found lot of people have done that but i couldn't find anyone have any example for that. If you can give me an example where I can receive the packet which I can feed to ffmpeg library to decode it that would be really appreciated. ? Thanks for the help. ? Regards, Abhishek Madaan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 8 12:28:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 8 Jul 2012 12:28:15 -0700 Subject: [Live-devel] Stream control issues In-Reply-To: References: Message-ID: <46AB1EE2-3D4A-4EE6-9A63-C0EC4AA2F114@live555.com> > The binary worked great under Windows-- I was able to load test an MPEG1 (non-ES) video and click to the middle of the video without a problem. I built the source-code under Linux on both a remote server and Ubuntu under a local VM, and the same video will load, but will: > > 1) NOT report it's duration properly. > 2) NOT allow the user to jump ahead. > > I am using VLC as the client. Does anyone have any advice? I downloaded the file that you reported http://host1.aws.randomingenuity.com/mailinglist/live/test-mpeg.mpg and tried running it with the "LIVE555 Media Server" on FreeBSD (I haven't had a chance to try Linux yet). It correctly reported the duration (21.368 seconds), and I was able to seek backwards and forwards through the stream using VLC. Nonetheless, 'trick play' operations on MPEG Program Stream files (like this) don't work as well as they do on (indexed) Transport Stream files - so if you have a choice of file types, then Transport Stream files are better. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiran.thakkar at gmail.com Fri Jul 6 22:02:00 2012 From: kiran.thakkar at gmail.com (Kiran P. Thakkar) Date: Sat, 7 Jul 2012 10:32:00 +0530 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server In-Reply-To: References: <001201cd5a85$d0a755b0$71f60110$@com> <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> Message-ID: Dear Ross, Thanks for your quick support. It is working now. It also comes to us notice that same type,same setting different camera has different metadata. Regards Kiran On Fri, Jul 6, 2012 at 6:48 PM, Ross Finlayson wrote: > OK, I figured out the problem - it was caused by the nonstandard > 'metadata' track in the back-end stream. Because this track is > non-standard, we can't proxy it, but that should not have prevetnted the > other, standard 'video' track from being proxied. > > I've now installed a new version "2012.07.06" of the "LIVE555 Streaming > Media" software that should fix this problem. Now, your front-end client > should be able to receive the 'video' track OK. > > Thanks for bringing this issue to our attention. > > > 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 brado at bighillsoftware.com Sun Jul 8 22:50:52 2012 From: brado at bighillsoftware.com (Brad O'Hearne) Date: Sun, 8 Jul 2012 22:50:52 -0700 Subject: [Live-devel] Recommended approach: pushing MP4/H.264 to server via RTP Message-ID: <77AB3D28-33B1-4E03-A200-EACE0AAC69D1@bighillsoftware.com> What is the recommended approach / LIVE555 sample app I should be looking app to push MP4/H.264 video to a server via RTP? Thanks, Brad From finlayson at live555.com Mon Jul 9 00:43:36 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jul 2012 00:43:36 -0700 Subject: [Live-devel] Recommended approach: pushing MP4/H.264 to server via RTP In-Reply-To: <77AB3D28-33B1-4E03-A200-EACE0AAC69D1@bighillsoftware.com> References: <77AB3D28-33B1-4E03-A200-EACE0AAC69D1@bighillsoftware.com> Message-ID: > What is the recommended approach / LIVE555 sample app I should be looking app to push MP4/H.264 video to a server via RTP? The best approach is to have the server directly integrated with your H.264 video source (rather than have the H.264 video source 'pushing' to anything). I.e., don't stream data to a server, and then have the server stream to clients; instead, just stream data directly to clients (via RTSP/RTP). The FAQ describes how to modify our RTSP server implementation (e.g., the "testOnDemandRTSPServer" demo application) to read from a video data source. But if you don't want to have clients accessing the data source directly (usually because you don't want more than one concurrent client doing so), then you could instead use a 'proxy' server (such as our existing "LIVE555 Proxy Server") sitting in front of your H.264 server. Then, remote clients (possibly multiple concurrent clients) would access the proxy server, which would then act as a (single) client to your H.264 server. Note that in each case you're not 'pushing' data at all. Instead, you are setting up a server for your H.264 video source, and a client (possibly a proxy) is 'pulling' from it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sathish.Manohar at aricent.com Sun Jul 8 23:50:40 2012 From: Sathish.Manohar at aricent.com (Sathish Kumar Manohar) Date: Mon, 9 Jul 2012 12:20:40 +0530 Subject: [Live-devel] Reg: Wav Support in RTSP Media Server In-Reply-To: <46AB1EE2-3D4A-4EE6-9A63-C0EC4AA2F114@live555.com> References: <46AB1EE2-3D4A-4EE6-9A63-C0EC4AA2F114@live555.com> Message-ID: <295BBDFA57CDE94BB3B04B5D5F28EE3202D4CE4BC5@GUREXMB02.ASIAN.AD.ARICENT.COM> Hi, I have a query regarding WAV support in RTSP media Server. We are planning to implement a rtp client for WAV(PCM) audio file. I want to know the RFC number that the WAV implementation complies to. I tried searching but could not find the RFC number for the same. Can someone give any information regarding this? Regards, Sathish Kumar M =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From naresh at vizexperts.com Mon Jul 9 01:10:11 2012 From: naresh at vizexperts.com (Naresh Sankapelly) Date: Mon, 9 Jul 2012 13:40:11 +0530 Subject: [Live-devel] OpenRTSP Issue Message-ID: <001801cd5daa$4410af20$cc320d60$@com> Hey everyone, I have an IP Camera that provide RTSP streams. I got two streams with names audio-G726-16-2 and video-MP4V-ES-1. I tried to multiplex these to streams using the following command of ffmpeg. ffmpeg -i audio-G726-16-2 -i video-MP4V-ES-1 -acodec copy -vcodec copy output.avi It gives and error like "audio-G726-16-2: Invalid data found when processing input. " I'm able to play this without any problem in VLC. I have to store these streams in AVI format. Can anyone let me know if there is any other way to do this? Thanks Naresh Reddy -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 9 01:15:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jul 2012 01:15:56 -0700 Subject: [Live-devel] Reg: Wav Support in RTSP Media Server In-Reply-To: <295BBDFA57CDE94BB3B04B5D5F28EE3202D4CE4BC5@GUREXMB02.ASIAN.AD.ARICENT.COM> References: <46AB1EE2-3D4A-4EE6-9A63-C0EC4AA2F114@live555.com> <295BBDFA57CDE94BB3B04B5D5F28EE3202D4CE4BC5@GUREXMB02.ASIAN.AD.ARICENT.COM> Message-ID: <93C1C891-F02B-4122-A484-8CBADBFA5E60@live555.com> > I have a query regarding WAV support in RTSP media Server. > > We are planning to implement a rtp client for WAV(PCM) audio file. Note that both "VLC" and "QuickTime Player" already support this. So you may not need to write your own client application. > I want to know the RFC number that the WAV implementation complies to. RFC 3551. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brado at bighillsoftware.com Mon Jul 9 01:31:39 2012 From: brado at bighillsoftware.com (Brad O'Hearne) Date: Mon, 9 Jul 2012 01:31:39 -0700 Subject: [Live-devel] Recommended approach: pushing MP4/H.264 to server via RTP In-Reply-To: References: <77AB3D28-33B1-4E03-A200-EACE0AAC69D1@bighillsoftware.com> Message-ID: Ross, Thanks for the response. Unfortunately, the environment in which the needed solution needs to be deployed is restricted by a few non-negotiables -- such as the need to store / transcode at the server, and a second client app which cannot be disrupted. So in other words, what is needed is this: 1) Desktop / Notebook with video cam captures H.264 ---> 2) Server needs to receive MP4 over RTP (not LIVE555, this existing server cannot be swapped out) ---> 3) Desktop / Notebook app consumes video in format other than H.264, this app cannot be disrupted. Basically, the scope of what needs to be accomplished is the streaming from 1) to 2). The server in 2) cannot be swapped out for several reasons. I just need to get the video from the source desktop / notebook to the server. Any further recommendations would be appreciated. Thanks, Brad On Jul 9, 2012, at 12:43 AM, Ross Finlayson wrote: >> What is the recommended approach / LIVE555 sample app I should be looking app to push MP4/H.264 video to a server via RTP? > > The best approach is to have the server directly integrated with your H.264 video source (rather than have the H.264 video source 'pushing' to anything). I.e., don't stream data to a server, and then have the server stream to clients; instead, just stream data directly to clients (via RTSP/RTP). The FAQ describes how to modify our RTSP server implementation (e.g., the "testOnDemandRTSPServer" demo application) to read from a video data source. > > But if you don't want to have clients accessing the data source directly (usually because you don't want more than one concurrent client doing so), then you could instead use a 'proxy' server (such as our existing "LIVE555 Proxy Server") sitting in front of your H.264 server. Then, remote clients (possibly multiple concurrent clients) would access the proxy server, which would then act as a (single) client to your H.264 server. > > Note that in each case you're not 'pushing' data at all. Instead, you are setting up a server for your H.264 video source, and a client (possibly a proxy) is 'pulling' from it. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 9 01:38:14 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jul 2012 01:38:14 -0700 Subject: [Live-devel] Recommended approach: pushing MP4/H.264 to server via RTP In-Reply-To: References: <77AB3D28-33B1-4E03-A200-EACE0AAC69D1@bighillsoftware.com> Message-ID: <9C13A2B3-5E0B-4640-98D5-DABCC6C69864@live555.com> > So in other words, what is needed is this: > > 1) Desktop / Notebook with video cam captures H.264 ---> 2) Server needs to receive MP4 over RTP (not LIVE555, this existing server cannot be swapped out) ---> 3) Desktop / Notebook app consumes video in format other than H.264, this app cannot be disrupted. > > Basically, the scope of what needs to be accomplished is the streaming from 1) to 2). OK, use an event loop that streams from a H.264 video source (perhaps using "DeviceSource" as a model) to a "H264VideoStreamDiscreteFramer" to a "H264VideoRTPSink". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 9 01:59:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jul 2012 01:59:02 -0700 Subject: [Live-devel] RTSPServer.Error:The total received frame size exceeds the client's buffer size (40).1276 bytes of trailing data will be dropped In-Reply-To: References: Message-ID: > My application shows following messages on screen. > > > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (40). This error message means exactly what it says: The size of the buffer that you provided to the "getNextFrame()" call is too small. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 9 02:05:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jul 2012 02:05:38 -0700 Subject: [Live-devel] about DeviceSource for multi channel encoder In-Reply-To: References: Message-ID: <98609C6E-6CD1-44BB-AB72-C75904ADCFC8@live555.com> Your message (plus the fact that your email address tells me that you're just a casual hobbyist) suggests that you might not understand how the 'event trigger' mechanism works. An 'event trigger' is intended to be used by an external thread to signal an event to your event loop. But I never saw the code for your event loop! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 9 02:12:48 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jul 2012 02:12:48 -0700 Subject: [Live-devel] H.264 OpenRTSP In-Reply-To: <1341605138.38090.YahooMailNeo@web114515.mail.gq1.yahoo.com> References: <1341605138.38090.YahooMailNeo@web114515.mail.gq1.yahoo.com> Message-ID: <1FBE967E-3194-4ED8-BEBB-8661E1EA6159@live555.com> > 1) When I am running OpenRTSP to play H.264 RTSP stream coming from a camera, it creates video-H264-1 file. What type of file is that? It's a H.264 video Elementary Stream file (with MPEG 'start codes' 0x00000001 inserted at the front of each NAL unit). > I tried to run this file in vlc player but it doesn't run at all. This is not a VLC mailing list. However, the problem is that VLC cannot figure out this file type just from its contents. However, if you rename the file with a ".h264" filename suffix, then VLC should be able to play it. > 2) I want to take the H.264 streaming using live555 library and feed to ffmpeg library This is not a "ffmpeg" mailing list. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marlon at scansoft.co.za Mon Jul 9 06:22:40 2012 From: Marlon at scansoft.co.za (Marlon Reid) Date: Mon, 9 Jul 2012 15:22:40 +0200 Subject: [Live-devel] Custom GSM file source Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8EDA@SSTSVR1.sst.local> Hi everyone, What is involved with creating a file source for GSM files? It appears that there isn't one at this stage. I took "Mp3FileSource" as an example, left only doGetNextFrame, MIMEType and getAttributes in the file. Will I need anything else? Are presentation times important, or don't I have to worry about it? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 9 09:52:00 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jul 2012 09:52:00 -0700 Subject: [Live-devel] Custom GSM file source In-Reply-To: <002962EA5927BE45B2FFAB0B5B5D67970A8EDA@SSTSVR1.sst.local> References: <002962EA5927BE45B2FFAB0B5B5D67970A8EDA@SSTSVR1.sst.local> Message-ID: > What is involved with creating a file source for GSM files? I don't know what GSM files look like. But if they contain fixed-size frames, then it should be quite simple to write a "GSMAudioFileSource" class. I *don't* suggest using "MP3FileSource" as a model; that code is old and crufty (plus, MP3 has variable-sized frames). Instead, use "ADTSAudioFileSource" or "AMRAudioFileSource" as a model. (Note, though, that those classes do synchronous file reading only. However, because you're Windoze people, that might be the only way you can read files anyway. But if you want to support asynchronous file reading as well, look at the "WAVAudioFileSource" code.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at MillerMicroSystems.com Mon Jul 9 10:09:20 2012 From: mike at MillerMicroSystems.com (Mike Miller) Date: Mon, 09 Jul 2012 12:09:20 -0500 Subject: [Live-devel] Problem stopping and restarting an RTSP client Message-ID: <4FFB1040.3070607@MillerMicroSystems.com> I am using a derivative of the testRTSPClient in an application. I am detecting stream failure by looking for missing frames. When I detect that the stream has been "silent" for too long, I need to close that stream and reopen it. I know the stream source is still working because other clients are still receiving. I am currently using only a single stream, but I left the code to handle multiple streams should I need it. When I need to restart a stream, I call this function: short StopAllRtspStreams(void) { *env << "\n\n*** StopAllRtspStreams()\n"; CaptureEnabled = false; if (initialized) StopExecThread(); for (int i = 0; i < rtspClientCount; ++i) { if (rtspClients[i] != NULL) { *env << "shutting down " << *rtspClients[i] << "\n"; shutdownStream(rtspClients[i]); } rtspClients[i] = NULL; } rtspClientCount = 0; // TODO anything else? return 0; } Then when restarting the stream, I call: short StartRtspStream(char * rtspURL, BufferPool_t * videoPool, BufferPool_t * leftPool, BufferPool_t * rightPool, BUFFER_CAPTURE_CALLBACK_PROC callback) { if (!initialized) StartExecThread(); *env << "\n\n*** StartRtspStream(" << rtspURL << ", ...)\n"; RTSPClient* rtspClient = ourRTSPClient::createNew(*env, rtspURL, RTSP_CLIENT_VERBOSITY_LEVEL, 0, videoPool, leftPool, rightPool, callback); if (rtspClient == NULL) { *env << "Failed to create a RTSP client for URL \"" << rtspURL << "\": " << env->getResultMsg() << "\n"; return 0; } rtspClient->sendDescribeCommand(continueAfterDESCRIBE); rtspClients[rtspClientCount] = rtspClient; ++rtspClientCount; return 1; } On the restart, the thing gets hung up waiting for the socket to connect: *** StartRtspStream(rtsp://192.168.233.1/test, ...) openConnection() entry Opening connection to 192.168.233.1, port 554, socket 2148... ...connection pending (10035) My code will detect that it didn't work, shut it down, and try to start it again. Over and over again. I'm guessing that I'm not shutting something down properly. I just can't figure out what. Suggestions? Mike [;-}> -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 9 11:42:28 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jul 2012 11:42:28 -0700 Subject: [Live-devel] Problem stopping and restarting an RTSP client In-Reply-To: <4FFB1040.3070607@MillerMicroSystems.com> References: <4FFB1040.3070607@MillerMicroSystems.com> Message-ID: <336E124E-5AC6-4DCB-8C4A-C3B6296A06F5@live555.com> > ...connection pending (10035) This appears to be the key to your problem. Something has failed - most likely at the server end, given that you had already stopped receiving RTP packets - and the client's OS is having trouble reconnecting to the server. (This is happening below the level of the LIVE555 code.) If - as appears likely - this is a problem with your server, then you're going to have to fix the problem at that end. (There's nothing that a client can do to fix a wedged server.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboom at channelislands.com Mon Jul 9 13:15:40 2012 From: mboom at channelislands.com (Michael L. Boom) Date: Mon, 9 Jul 2012 13:15:40 -0700 Subject: [Live-devel] Looking For Version "2012.06.26" / 1340668800 Message-ID: I made some change to the code but I have no idea what anymore. I need the unmodified version to compare. Does anyone have this version? I realize old code isn't supported or made available but I was hoping someone may have this. It would save me a lot of time. #define LIVEMEDIA_LIBRARY_VERSION_STRING "2012.06.26" #define LIVEMEDIA_LIBRARY_VERSION_INT 1340668800 -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Mon Jul 9 15:06:36 2012 From: warren at etr-usa.com (Warren Young) Date: Mon, 09 Jul 2012 16:06:36 -0600 Subject: [Live-devel] Looking For Version "2012.06.26" / 1340668800 In-Reply-To: References: Message-ID: <4FFB55EC.5040104@etr-usa.com> On 7/9/2012 2:15 PM, Michael L. Boom wrote: > I need the unmodified version to compare. Googling the file name in quotes gave me this: http://goo.gl/SdU3e I also direct you to the FAQ on modifying the code: http://www.live555.com/liveMedia/faq.html#modifying-and-extending *Always* make a pristine of a source tree before hacking on it, if you haven't checked it into a VCS first to get the same effect. Better, contribute the changes, in hopes Ross will merge them into trunk so you don't have to keep maintaining your private fork. From chao.yuan at alcatel-lucent.com Mon Jul 9 23:26:16 2012 From: chao.yuan at alcatel-lucent.com (Yuan, Chao (Chao)** CTR **) Date: Tue, 10 Jul 2012 08:26:16 +0200 Subject: [Live-devel] Pls give suggestion about the testReplicator.cpp Message-ID: <5FD979BDF2350C4796619C0AC619B38802F113DB48@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> All, I used the live555 lib to make a simple RTSP server, my server IP is 135.240.130.30, the inputPort is 1236, the outputPort is 8556, One phone can send TS packet to 1236 port, another phone can get the packets from rtsp://135.240.130.30:8556/mobileLiveVideo, This works fine. However, I also want to store/save this TS stream source on the live555 server into a stream file,for example(test.ts), after I see the code in testProgs/testReplicator.cpp, I add some code to do this: unsigned fOurSessionId; Port clientRTPPort(0), clientRTCPPort(0), serverRTPPort(0), serverRTCPPort(0); netAddressBits destinationAddress = 0; u_int8_t destinationTTL = 0; Boolean isMulticast = False; void* streamToken; subsess->getStreamParameters(fOurSessionId, 0, clientRTPPort,clientRTCPPort, 0,0,0, destinationAddress,destinationTTL, isMulticast, serverRTPPort,serverRTCPPort, streamToken); // get the source FramedSource* source = subsess->getStreamSource(streamToken); StreamReplicator* replicator = StreamReplicator::createNew(*env, source); // Then create a network (UDP) 'sink' object to receive a replica of the input stream, and start it. // If you wish, you can duplicate this line - with different network addresses and ports - to create multiple output UDP streams: startReplicaUDPSink(replicator,"135.240.130.30",8556); // Then create a file 'sink' object to receive a replica of the input stream, and start it. // If you wish, you can duplicate this line - with a different file name - to create multiple output files: startReplicaFileSink(replicator, "test.ts"); startReplicaFileSink(replicator, "test2.ts"); *env<<"\nstartReplicaFileSink\n"; The startReplicaUDPSink and startReplicaFileSink is same as in testProgs/testReplicator.cpp. The problem is the test.ts and test2.ts can save the TS packet correctly, but the phone can not get packets from rtsp://135.240.130.30:8556/mobileLiveVideo, And an error on my server occurred: FramedSource[0x1fea260]::getNextFrame(): attempting to read more than once at the same time! Aborted Can anyone tell we what's wrong? Thank you. BR, Chao,Yuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 10 05:13:53 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Jul 2012 05:13:53 -0700 Subject: [Live-devel] Pls give suggestion about the testReplicator.cpp In-Reply-To: <5FD979BDF2350C4796619C0AC619B38802F113DB48@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> References: <5FD979BDF2350C4796619C0AC619B38802F113DB48@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> Message-ID: <9F666E6D-2656-48BF-90C3-0258C97E3F32@live555.com> The basic problem is your code's use of the port number 8556. First, you shouldn't think of it as being the server's 'output' port. Instead, it's the 'control' port that the server uses for incoming RTSP connections from clients. (The actual RTP/RTCP stream 'output' uses other port numbers, which will differ for each client.) Anyway, the key point is that because the server uses port number 8556 for RTSP, your code can't reuse it. Also, you should not be calling "getStreamParameters()" and "getStreamSource()" at all. Those functions are only used internally by our library code to implement RTSP server functionality; you should not be calling them yourself in your code. Because your server is receiving Transport Stream packets on a UDP port (1236, in your case), and then re-serving this data via RTSP, you should just be using a variant of the code that's used (in lines 330-356 of "testProgs/testOnDemandRTSPServer.cpp") to demonstrate this functionality in the "testOnDemandRTSPServer" demo application. The change that you would make is that instead of using the "MPEG2TransportUDPServerMediaSubsession" class, you would use a *subclass* of this - that you would write. For the purposes of this email, let's call this subclass "modifiedMPEG2TransportUDPServerMediaSubsession". Your "modifiedMPEG2TransportUDPServerMediaSubsession" class would be a subclass of "MPEG2TransportUDPServerMediaSubsession", and would reimplement just one virtual function: "createNewStreamSource()". Your reimplemented "createNewStreamSource()" function would look something like this: FramedSource* modifiedMPEG2TransportUDPServerMediaSubsession ::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate) { FramedSource* inputSource = MPEG2TransportUDPServerMediaSubsession:: createNewStreamSource(clientSessionId, estBitrate); // call the parent class's implementation first StreamReplicator* replicator = StreamReplicator::createNew(envir(), inputSource); startReplicaFileSink(replicator, "test.ts"); startReplicaFileSink(replicator, "test2.ts"); return replicator->createStreamReplica(); } I.e., your code would replace the input source stream with a replica, while creating two more replicas for use in output files. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboom at channelislands.com Tue Jul 10 14:45:24 2012 From: mboom at channelislands.com (Michael L. Boom) Date: Tue, 10 Jul 2012 14:45:24 -0700 Subject: [Live-devel] Range Header Message-ID: <8CE79E3CB2664753A3AA216BB47D82A7@Work> Lets say I am 30 seconds into the clip I am watching. If I say play "Range: npt=-60" it will return "Range: npt=0-" and play from the start. When I use "Range: npt=now-60" it doesn't return a Range header but continues from where it left off and stops at 60 seconds into the commercial IF the scale is 1.0. If the scale header is higher than 1.0 it will play way beyond 60 seconds (it does stop after a while though). Isn't the keyword "now" reserved for live events? Basically "Range: npt=-60" doesn't seem to work but "Range: npt=now-60" does when the scale is 1.0. When the scale is higher than 1.0 it does the same thing excepts plays way beyond 60 seconds into the clip. PLAY rtsp://192.168.1.139/movies/CI-PRIM/american_chopper/Sr_v_Jr_D1-Title1.mp4.ts RTSP/1.0 -- is proxy gen: FALSE CSeq: 105 Range: npt=-60.000 Scale: 1.501502 Session: 40C4F683 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) RTSP/1.0 200 OK Accept: 5554/movies/CI-PRIM/american_chopper/Sr_v_Jr_D1-Title1.mp4.ts/*;seq=0;rtptime=0 CSeq: 105 Date: Tue, Jul 10 2012 21:24:17 GMT Range: npt=0.000- RTP-Info: url=rtsp://192.168.1.139/movies/CI-PRIM/american_chopper/Sr_v_Jr_D1-Title1.mp4.ts RTSP/1.0 Scale: 2.000000 Session: 40C4F683 ------------------------------------ PLAY rtsp://192.168.1.139/movies/CI-PRIM/american_chopper/Sr_v_Jr_D1-Title1.mp4.ts RTSP/1.0 -- is proxy gen: FALSE CSeq: 105 Range: npt=now-60.000 Scale: 1.501502 Session: 4109C0C6 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) RTSP/1.0 200 OK Accept: 5554/movies/CI-PRIM/american_chopper/Sr_v_Jr_D1-Title1.mp4.ts/*;seq=0;rtptime=0 CSeq: 105 Date: Tue, Jul 10 2012 21:33:51 GMT RTP-Info: url=rtsp://192.168.1.139/movies/CI-PRIM/american_chopper/Sr_v_Jr_D1-Title1.mp4.ts RTSP/1.0 Scale: 2.000000 Session: 4109C0C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From csavtche at gmail.com Mon Jul 9 11:56:54 2012 From: csavtche at gmail.com (Constantin Savtchenko) Date: Mon, 9 Jul 2012 14:56:54 -0400 Subject: [Live-devel] Problem stopping and restarting an RTSP client In-Reply-To: <4FFB1040.3070607@MillerMicroSystems.com> References: <4FFB1040.3070607@MillerMicroSystems.com> Message-ID: > > if (rtspClients[i] != NULL) > > { > > *env << "shutting down " << *rtspClients[i] << "\n"; > > shutdownStream(rtspClients[i]); > > } > > rtspClients[i] = NULL; > > } > > Mike, Could you send your shutdownStream()? Perhaps you're not tearing down the MediaSession? Also are you doing a Medium::close(rtspClients[i]) anywhere? My program successfully restarts RTSP streams by sending TeardownRequests and closing the rtsp client. (Closing the client turns out to be important, didn't check why, but it seems like it maintains some contextual information somewhere.) Constantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhg84 at gmail.com Wed Jul 11 04:50:48 2012 From: saurabhg84 at gmail.com (Saurabh Gandhi) Date: Wed, 11 Jul 2012 17:20:48 +0530 Subject: [Live-devel] Error message while using live555 proxy server Message-ID: Hello everyone, I am getting the following error message (H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input) while using live555 proxyserver to stream RTSP streams from a few of my IP cameras. This error seems to appear in many IP cameras from a particular vendor. However, it does not appear for other IP cameras. Is it a camera related error? Kindly advise. -- Regards, Saurabh Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ketangholap1990 at gmail.com Mon Jul 9 22:53:54 2012 From: ketangholap1990 at gmail.com (Ketan Gholap) Date: Tue, 10 Jul 2012 11:23:54 +0530 Subject: [Live-devel] RTSPServer.Error:The total received frame size exceeds the client's buffer size (40).1276 bytes of trailing data will be dropped In-Reply-To: References: Message-ID: *Hello Sir As u can u see from my last mail i am using the code from your file testOnDemandRTSPServer.cpp under the section/ A MPEG-2 Transport Stream, coming from a live UDP (raw-UDP or RTP/UDP) source. As u said that "my error message means exactly what it says: The size of the buffer that you provided to the "getNextFrame()" call is too small." your reply put me into confusion that from the same source for the first START_STREAM message it works and for the second START_STREAM message it does'nt work,u say we need to increase the buffer size,how can it be possible? Where are u allocating buffer that are used by the "getNextFrame()" function ? Thanks * -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 11 09:31:14 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 11 Jul 2012 09:31:14 -0700 Subject: [Live-devel] Error message while using live555 proxy server In-Reply-To: References: Message-ID: <96B18209-3B6F-44CB-AFE9-9560FA298EB2@live555.com> > I am getting the following error message (H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input) while using live555 proxyserver to stream RTSP streams from a few of my IP cameras. This error seems to appear in many IP cameras from a particular vendor. However, it does not appear for other IP cameras. Is it a camera related error? Yes, the cameras (for which you see the error message) are incorrectly including MPEG 'start codes' - i.e., 0x00 0x00 0x00 0x01 bytes - at the front of the NAL units that are packed into RTP packets. Please contact the vendor of those cameras, telling them that they are not in compliance with the H.264/RTP standard: RFC 3984. (Note in particular, section 1.3 of RFC 3984, which describes the first byte of each NAL unit that is packed into a RTP packet.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chao.yuan at alcatel-lucent.com Thu Jul 12 02:17:56 2012 From: chao.yuan at alcatel-lucent.com (Yuan, Chao (Chao)** CTR **) Date: Thu, 12 Jul 2012 11:17:56 +0200 Subject: [Live-devel] Pls give suggestion about the testReplicator.cpp In-Reply-To: <9F666E6D-2656-48BF-90C3-0258C97E3F32@live555.com> References: <5FD979BDF2350C4796619C0AC619B38802F113DB48@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> <9F666E6D-2656-48BF-90C3-0258C97E3F32@live555.com> Message-ID: <5FD979BDF2350C4796619C0AC619B38802F113DCAD@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> Hi, Thank you very much, I did as you say, and now it works fine: the ts packets can save as local file. If I want to save ts packets to a seial of files: For example, when I found a I frame (h264 encoded, we only have I frame and P frame), I save the next packets to a file: 1.ts, when I found a next I frame,I save next packets to 2.ts,.... I tried: MediaSink* sink = FileSink::createNew(envir(), outputFileName, 20000,true); but the saved each files are 1316B , because the source send packets are 188*7. What should I do? BR, Chao, Yuan ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, July 10, 2012 8:14 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Pls give suggestion about the testReplicator.cpp The basic problem is your code's use of the port number 8556. First, you shouldn't think of it as being the server's 'output' port. Instead, it's the 'control' port that the server uses for incoming RTSP connections from clients. (The actual RTP/RTCP stream 'output' uses other port numbers, which will differ for each client.) Anyway, the key point is that because the server uses port number 8556 for RTSP, your code can't reuse it. Also, you should not be calling "getStreamParameters()" and "getStreamSource()" at all. Those functions are only used internally by our library code to implement RTSP server functionality; you should not be calling them yourself in your code. Because your server is receiving Transport Stream packets on a UDP port (1236, in your case), and then re-serving this data via RTSP, you should just be using a variant of the code that's used (in lines 330-356 of "testProgs/testOnDemandRTSPServer.cpp") to demonstrate this functionality in the "testOnDemandRTSPServer" demo application. The change that you would make is that instead of using the "MPEG2TransportUDPServerMediaSubsession" class, you would use a *subclass* of this - that you would write. For the purposes of this email, let's call this subclass "modifiedMPEG2TransportUDPServerMediaSubsession". Your "modifiedMPEG2TransportUDPServerMediaSubsession" class would be a subclass of "MPEG2TransportUDPServerMediaSubsession", and would reimplement just one virtual function: "createNewStreamSource()". Your reimplemented "createNewStreamSource()" function would look something like this: FramedSource* modifiedMPEG2TransportUDPServerMediaSubsession ::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate) { FramedSource* inputSource = MPEG2TransportUDPServerMediaSubsession:: createNewStreamSource(clientSessionId, estBitrate); // call the parent class's implementation first StreamReplicator* replicator = StreamReplicator::createNew(envir(), inputSource); startReplicaFileSink(replicator, "test.ts"); startReplicaFileSink(replicator, "test2.ts"); return replicator->createStreamReplica(); } I.e., your code would replace the input source stream with a replica, while creating two more replicas for use in output files. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chao.yuan at alcatel-lucent.com Thu Jul 12 02:31:36 2012 From: chao.yuan at alcatel-lucent.com (Yuan, Chao (Chao)** CTR **) Date: Thu, 12 Jul 2012 11:31:36 +0200 Subject: [Live-devel] Pls give suggestion about the testReplicator.cpp In-Reply-To: <9F666E6D-2656-48BF-90C3-0258C97E3F32@live555.com> References: <5FD979BDF2350C4796619C0AC619B38802F113DB48@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> <9F666E6D-2656-48BF-90C3-0258C97E3F32@live555.com> Message-ID: <5FD979BDF2350C4796619C0AC619B38802F113DCAE@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> Hi, Thank you very much, I did as you say, and now it works fine: the ts packets can save as local file. If I want to save ts packets to a seial of files: For example, when I found a I frame (h264 encoded, we only have I frame and P frame), I save the next packets to a file: 1.ts, when I found a next I frame,I save next packets to 2.ts,.... I tried: MediaSink* sink = FileSink::createNew(envir(), outputFileName, 20000,true); but the saved each files are 1316B , because the source send packets are 188*7. What should I do? BR, Chao, Yuan ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, July 10, 2012 8:14 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Pls give suggestion about the testReplicator.cpp The basic problem is your code's use of the port number 8556. First, you shouldn't think of it as being the server's 'output' port. Instead, it's the 'control' port that the server uses for incoming RTSP connections from clients. (The actual RTP/RTCP stream 'output' uses other port numbers, which will differ for each client.) Anyway, the key point is that because the server uses port number 8556 for RTSP, your code can't reuse it. Also, you should not be calling "getStreamParameters()" and "getStreamSource()" at all. Those functions are only used internally by our library code to implement RTSP server functionality; you should not be calling them yourself in your code. Because your server is receiving Transport Stream packets on a UDP port (1236, in your case), and then re-serving this data via RTSP, you should just be using a variant of the code that's used (in lines 330-356 of "testProgs/testOnDemandRTSPServer.cpp") to demonstrate this functionality in the "testOnDemandRTSPServer" demo application. The change that you would make is that instead of using the "MPEG2TransportUDPServerMediaSubsession" class, you would use a *subclass* of this - that you would write. For the purposes of this email, let's call this subclass "modifiedMPEG2TransportUDPServerMediaSubsession". Your "modifiedMPEG2TransportUDPServerMediaSubsession" class would be a subclass of "MPEG2TransportUDPServerMediaSubsession", and would reimplement just one virtual function: "createNewStreamSource()". Your reimplemented "createNewStreamSource()" function would look something like this: FramedSource* modifiedMPEG2TransportUDPServerMediaSubsession ::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate) { FramedSource* inputSource = MPEG2TransportUDPServerMediaSubsession:: createNewStreamSource(clientSessionId, estBitrate); // call the parent class's implementation first StreamReplicator* replicator = StreamReplicator::createNew(envir(), inputSource); startReplicaFileSink(replicator, "test.ts"); startReplicaFileSink(replicator, "test2.ts"); return replicator->createStreamReplica(); } I.e., your code would replace the input source stream with a replica, while creating two more replicas for use in output files. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 12 02:46:04 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Jul 2012 02:46:04 -0700 Subject: [Live-devel] Pls give suggestion about the testReplicator.cpp In-Reply-To: <5FD979BDF2350C4796619C0AC619B38802F113DCAE@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> References: <5FD979BDF2350C4796619C0AC619B38802F113DB48@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> <9F666E6D-2656-48BF-90C3-0258C97E3F32@live555.com> <5FD979BDF2350C4796619C0AC619B38802F113DCAE@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> Message-ID: <963C3607-08D0-4683-AF0C-BC4A9969CC3D@live555.com> > What should I do? For starters, DO NOT post the same question to the mailing list more than once. Also, please trim your messages (so that you're not quoting the entire message that you're responding to). This is basic email 'netiquette'. I didn't really understand your question, but it sounds like you want to demultiplex Transport Stream data into its constituent video and audio elementary streams. Unfortunately, we don't provide any Transport Stream demultiplexing code, so this is something that you would need to write yourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chao.yuan at alcatel-lucent.com Fri Jul 13 00:45:03 2012 From: chao.yuan at alcatel-lucent.com (Yuan, Chao (Chao)** CTR **) Date: Fri, 13 Jul 2012 09:45:03 +0200 Subject: [Live-devel] split live ts packets Message-ID: <5FD979BDF2350C4796619C0AC619B38802F113DD0F@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> Hi, All First , I'm really sorry about posting the same question to the mailing list twice yesterday. Because my mail box received the mail which I sent, I thought I wrote a wrong mail address , but after I sent the same mail once again, and received the mail again, I recognized I have made a mistake. I am really sorry! Now I will post my question: My work is, one android phone send live ts packets to live555 server, other phones can connected to live555 rtsp server and can play the ts packets (I use ffmpeg to decode and play,because ffmpeg support rtsp protocol) Now these works have done. But these works can not save/store the live ts packets to local file, under Ross Finlayson's help, I resolve the problem, I can save the ts packets to a local file, for example: test.ts.[1] My ts encoder is h264/video, aac/audio. The h264 encoder only have I frame and P frame, no B frame. But now I need to save the ts packets to a serial of files, like this: When live555 server receive a I frame, I will save the next packets to 1.ts until the server receive next I frame. Because my ts only have I frame and P frame, thus 1.ts contains: I P P P P P P P P P.... 2.ts contains: I P P P P P P P... 3.ts contains: I P P P P P P P.... The all small ts files can be combined to a big ts file: test.ts, the same as the [1]. I think one solution: I write another program to detected the test.ts file, and split it to 1.ts 2.ts 3.ts 4.ts .... until no live ts packets coming. Or may anyone can tell me some other solution? BR, Chao, Yuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 13 18:39:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Jul 2012 18:39:51 -0700 Subject: [Live-devel] Range Header In-Reply-To: <8CE79E3CB2664753A3AA216BB47D82A7@Work> References: <8CE79E3CB2664753A3AA216BB47D82A7@Work> Message-ID: Thanks for the note. I have now installed a new version (2012.07.14) of the "LIVE555 Streaming Media" code that updates the RTSP server implementation to properly handle "Range:" headers like "Range: npt=-60". (The prebuilt binary versions of the "LIVE555 Media Server" have not yet been updated; for the next few days, if you want to get this change, you will need to download and build the server from source code.) And yes, the keyword "now" is supposed to be reserved for live events, but in the spirit of "be liberal in what you accept", we also handle it if is used for a prerecorded stream. (Clients, however, should not be using it for such streams.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.longney at logica.com Sun Jul 15 18:37:19 2012 From: ian.longney at logica.com (Longney, Ian) Date: Mon, 16 Jul 2012 11:37:19 +1000 Subject: [Live-devel] Issue with proxyserver and multiple clients Message-ID: Hi, I am currently using the latest version of the live555 proxy server to connect to a Vivotek IP camera streaming H264 over RTSP. Whenever I view the unicast stream from the proxy server with a single client everything works fine. However, when I connect a second client the first client freezes. I have tried both VLC and Quicktime to view the stream and the same thing happens on both. I am running on a 64 bit Windows 7 platform. Any assistance would be much appreciated. Thank you Ian Longney | MOSAIC Product Centre Manager Ground Floor, 436 Elgar Road, Box Hill, VIC 3128 | Australia T: +61 3 9843 0661 | M: +61 412 279 861 ian.longney at logica.com | www.logica.com Logica Australia Pty Ltd - Registered in Australia (ABN 39 001 260 699) Registered Office: Level 13, 100 Pacific Highway, North Sydney, NSW 2060, Australia Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 15 19:36:50 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 15 Jul 2012 19:36:50 -0700 Subject: [Live-devel] Issue with proxyserver and multiple clients In-Reply-To: References: Message-ID: <19D3347D-AFDE-46ED-81BB-DD738B155A8B@live555.com> > I am currently using the latest version of the live555 proxy server to connect to a Vivotek IP camera streaming H264 over RTSP. Whenever I view the unicast stream from the proxy server with a single client everything works fine. However, when I connect a second client the first client freezes. I have tried both VLC and Quicktime to view the stream and the same thing happens on both. I am running on a 64 bit Windows 7 platform. > > Any assistance would be much appreciated. As stated (in boldface) on our web page: If you are having trouble with the proxy server, then we recommend using the "-V" option to try to figure out what's wrong. Also, I suggest running "testRTSPClient" (rather than VLC or QuickTime Player) as your RTSP client, at least initially, to help figure out what's happening. It would also be useful to know if the problem that you're seeing (with the first client 'freezing' when the second client connects) happens when the two clients are running on different computers, or only if the two clients are running on the same computer. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilchen at gmx.net Fri Jul 13 02:58:11 2012 From: nilchen at gmx.net (Roman Carlin) Date: Fri, 13 Jul 2012 11:58:11 +0200 Subject: [Live-devel] Limit fps in trick play mode Message-ID: <20120713095811.66240@gmx.net> Hello, In case of trick play (fast forward and rewind) LIVE555 Media Server sends more frames per second than in normal play mode. This requires much more bandwidth (I only have a DSL connection for the stream). Is it possible to limit the number of frames per second in this case to reduce the bandwidth usage (ex. 2 fps)? thanks Roman From ketangholap1990 at gmail.com Fri Jul 13 07:00:55 2012 From: ketangholap1990 at gmail.com (Ketan Gholap) Date: Fri, 13 Jul 2012 07:00:55 -0700 Subject: [Live-devel] TRYED TO FIND BIT RATE BUT NOT GETTING Message-ID: Hello Sir As told by you i try'ed to find the bit/byte rte but every time i am getting zero could please tell me where i am wrong.I would be very thank full to you // A test program that reads a MPEG-2 Transport Stream file, // and streams it using RTP // main program #include "liveMedia.hh" #include "BasicUsageEnvironment.hh" #include "GroupsockHelper.hh" // To stream using "source-specific multicast" (SSM), uncomment the following: //#define USE_SSM 1 #ifdef USE_SSM Boolean const isSSM = True; #else Boolean const isSSM = False; #endif // To set up an internal RTSP server, uncomment the following: #define IMPLEMENT_RTSP_SERVER 1 // (Note that this RTSP server works for multicast only) #define TRANSPORT_PACKET_SIZE 188 #define TRANSPORT_PACKETS_PER_NETWORK_PACKET 7 // The product of these two numbers must be enough to fit within a network packet UsageEnvironment* env; char const* inputFileName = "test.ts"; FramedSource* videoSource; RTPSink* videoSink; int64_t uSecsToDelay=1000000; void play(); // forward void a(RTPSink* sink); void periodicQOSMeasurement1(void* clientData); int CreateINI(); char *sstreamip; int SSport; int main(int argc, char** argv) { // Begin by setting up our usage environment: TaskScheduler* scheduler = BasicTaskScheduler::createNew(); env = BasicUsageEnvironment::createNew(*scheduler); //CreateINI(); // Create 'groupsocks' for RTP and RTCP: char const* destinationAddressStr #ifdef USE_SSM = "232.255.42.42"; #else = "239.255.42.42"; // Note: This is a multicast address. If you wish to stream using // unicast instead, then replace this string with the unicast address // of the (single) destination. (You may also need to make a similar // change to the receiver program.) #endif const unsigned short rtpPortNum = 1234; const unsigned short rtcpPortNum = rtpPortNum+1; const unsigned char ttl = 7; // low, in case routers don't admin scope struct in_addr destinationAddress; destinationAddress.s_addr = our_inet_addr(destinationAddressStr); const Port rtpPort(rtpPortNum); const Port rtcpPort(rtcpPortNum); Groupsock rtpGroupsock(*env, destinationAddress, rtpPort, ttl); Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl); #ifdef USE_SSM rtpGroupsock.multicastSendOnly(); rtcpGroupsock.multicastSendOnly(); #endif // Create an appropriate 'RTP sink' from the RTP 'groupsock': videoSink = SimpleRTPSink::createNew(*env, &rtpGroupsock, 33, 90000, "video", "MP2T", 1, True, False /*no 'M' bit*/); // Create (and start) a 'RTCP instance' for this RTP sink: const unsigned estimatedSessionBandwidth = 5000; // in kbps; for RTCP b/w share const unsigned maxCNAMElen = 100; unsigned char CNAME[maxCNAMElen+1]; gethostname((char*)CNAME, maxCNAMElen); CNAME[maxCNAMElen] = '\0'; // just in case #ifdef IMPLEMENT_RTSP_SERVER RTCPInstance* rtcp = #endif RTCPInstance::createNew(*env, &rtcpGroupsock, estimatedSessionBandwidth, CNAME, videoSink, NULL /* we're a server */, isSSM); // Note: This starts RTCP running automatically #ifdef IMPLEMENT_RTSP_SERVER RTSPServer* rtspServer = RTSPServer::createNew(*env); // Note that this (attempts to) start a server on the default RTSP server // port: 554. To use a different port number, add it as an extra // (optional) parameter to the "RTSPServer::createNew()" call above. if (rtspServer == NULL) { *env << "Failed to create RTSP server: " << env->getResultMsg() << "\n"; exit(1); } ServerMediaSession* sms = ServerMediaSession::createNew(*env, "testStream", inputFileName, "Session streamed by \"testMPEG2TransportStreamer\"", isSSM); sms->addSubsession(PassiveServerMediaSubsession::createNew(*videoSink, rtcp)); rtspServer->addServerMediaSession(sms); char* url = rtspServer->rtspURL(sms); *env << "Play this stream using the URL \"" << url << "\"\n"; delete[] url; #endif // Finally, start the streaming: *env << "Beginning streaming...\n"; play(); a(videoSink); env->taskScheduler().doEventLoop(); // does not return return 0; // only to prevent compiler warning } void afterPlaying(void* /*clientData*/) { *env << "...done reading from file\n"; videoSink->stopPlaying(); Medium::close(videoSource); // Note that this also closes the input file that this source read from. play(); } void play() { unsigned const inputDataChunkSize = TRANSPORT_PACKETS_PER_NETWORK_PACKET*TRANSPORT_PACKET_SIZE; // Open the input file as a 'byte-stream file source': ByteStreamFileSource* fileSource = ByteStreamFileSource::createNew(*env, inputFileName, inputDataChunkSize); if (fileSource == NULL) { *env << "Unable to open file \"" << inputFileName << "\" as a byte-stream file source\n"; exit(1); } // Create a 'framer' for the input source (to give us proper inter-packet gaps): videoSource = MPEG2TransportStreamFramer::createNew(*env, fileSource); // Finally, start playing: *env << "Beginning to read from file...\n"; videoSink->startPlaying(*videoSource, afterPlaying, videoSink); } *void periodicQOSMeasurement1(void* clientData) * *{* * struct timeval timeNow;* * gettimeofday(&timeNow, NULL); RTPSink* sink = (RTPSink*)clientData; * * int s1=timeNow.tv_sec;* * printf("value of s1 %d\n",s1);* * int o1= videoSink->octetCount();* * printf("value of o1 %d\n",o1);* * int s2=timeNow.tv_sec;* * printf("value of s2 %d\n",s2);* * * * int o2= videoSink->octetCount();* * printf("value of o2 %d\n",o2);* * double mbits_sent = (o2 - o1) / 1024.0 / 1024.0 / (s2 - s1);* * printf("mbits_sent is %ld\n",mbits_sent);* * env->taskScheduler().**scheduleDelayedTask(**uSecsToDelay, (TaskFunc*)** periodicQOSMeasurement1,**clientData);* * * * * * * * * * * *}* *void a(RTPSink* sink)* *{* * //periodicQOSMeasurement1((**void*)NULL);* * periodicQOSMeasurement1(sink);* *}* -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhg84 at gmail.com Fri Jul 13 22:22:32 2012 From: saurabhg84 at gmail.com (Saurabh Gandhi) Date: Sat, 14 Jul 2012 10:52:32 +0530 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server In-Reply-To: References: <001201cd5a85$d0a755b0$71f60110$@com> <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> Message-ID: Dear Ross, We would be grateful if you could elaborate on what you mean by non-standard metadata since we are trying to report the same issue to our camera vendor. Awaiting your response. Thank you. -- Regards, Saurabh Gandhi On Sat, Jul 7, 2012 at 10:32 AM, Kiran P. Thakkar wrote: > Dear Ross, > > Thanks for your quick support. It is working now. > > It also comes to us notice that same type,same setting different camera > has different metadata. > > Regards > Kiran > > On Fri, Jul 6, 2012 at 6:48 PM, Ross Finlayson wrote: > >> OK, I figured out the problem - it was caused by the nonstandard >> 'metadata' track in the back-end stream. Because this track is >> non-standard, we can't proxy it, but that should not have prevetnted the >> other, standard 'video' track from being proxied. >> >> I've now installed a new version "2012.07.06" of the "LIVE555 Streaming >> Media" software that should fix this problem. Now, your front-end client >> should be able to receive the 'video' track OK. >> >> Thanks for bringing this issue to our attention. >> >> >> 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 >> >> > > _______________________________________________ > 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 zanglan at yahoo.com Sun Jul 15 02:47:22 2012 From: zanglan at yahoo.com (Lan Zang) Date: Sun, 15 Jul 2012 17:47:22 +0800 (CST) Subject: [Live-devel] How to remove ServerMediaServer dynamically Message-ID: <1342345642.51211.YahooMailNeo@web15804.mail.cnb.yahoo.com> Hi, dear author, I am using live555 media server. I am trying to remove media by calling RTSPServer::removeServerMediaSession(session); This media is created by calling RTSPServer::addServerMediaSession(session); The problem is live555 server will complain "BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor" then abort immediately.? The server won't terminate only if there is no media player connected. I want to know if there are extra steps to remove current media stream? Regards, Lan Zang(Sander) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at MillerMicroSystems.com Mon Jul 16 09:45:23 2012 From: mike at MillerMicroSystems.com (Mike Miller) Date: Mon, 16 Jul 2012 11:45:23 -0500 Subject: [Live-devel] Problem stopping and restarting an RTSP client Message-ID: <50044523.8060406@MillerMicroSystems.com> This is not a server problem. When I'm having the problem restarting the stream to Live555, the VLC client is still happily receiving and displaying video. The source is an IP-connected camera and seems stable. In the failure case, even if the old connection to the camera were buggered up, Live555 is opening another socket to the camera, which should still work. I have also updated to the 2012.07.14 source code, to no avail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 16 14:27:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jul 2012 14:27:05 -0700 Subject: [Live-devel] Problem stopping and restarting an RTSP client In-Reply-To: <50044523.8060406@MillerMicroSystems.com> References: <50044523.8060406@MillerMicroSystems.com> Message-ID: <6CCE18E3-D6CA-41A0-B927-62252868CE3D@live555.com> > This is not a server problem. When I'm having the problem restarting the stream to Live555, the VLC client is still happily receiving and displaying video. OK, so if the problem is not at the server, then it must be the client's OS that's wedged (somehow). The problem is probably *not* with the application-level (i.e., LIVE555 code). (Note that VLC also uses the LIVE555 library for its RTSP client support.) Is the working VLC client running on the same computer as your wedged client? I.e., once your client application stops working, are any other RTSP client applications able to work on the same computer? If you terminated the wedged client application, are you then able to restart it OK? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 16 16:56:19 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jul 2012 16:56:19 -0700 Subject: [Live-devel] Limit fps in trick play mode In-Reply-To: <20120713095811.66240@gmx.net> References: <20120713095811.66240@gmx.net> Message-ID: <20D9449F-3FEA-416C-9EA8-F8D905D2D497@live555.com> > In case of trick play (fast forward and rewind) I presume you're talking about streaming indexed MPEG Transport Stream files here... > LIVE555 Media Server sends more frames per second than in normal play mode. No it doesn't. It *never* sends more frames per second than normal play mode (and, in fact, for small scale values (less than the number of frames per I-frame), it will send fewer frames per second than in normal play mode). However, because the frames that it sends (in fast-forward or reverse play) are I-frames only, the average frame *size* (in bytes) will be larger than in normal play mode, thereby leading to a larger bit rate. There is no way to overcome this - sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 16 17:05:31 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jul 2012 17:05:31 -0700 Subject: [Live-devel] Unable to stream RTSP using Live555 proxy server In-Reply-To: References: <001201cd5a85$d0a755b0$71f60110$@com> <90A4EEE3-553F-401D-9F43-1FAC58FCFA44@live555.com> Message-ID: <1A508BDA-A22B-4A5D-B75C-4B09B1B5878C@live555.com> > We would be grateful if you could elaborate on what you mean by non-standard metadata I mean that the "metadata" keyword used in the following SDP lines in your camera's stream: m=metadata 0 RTP/AVP 97 a=rtpmap:97 METADATA/64000 are non-standard - i.e., not defined by any IETF RFC (or even a pre-standard Internet Draft). Therefore, because we have no way of knowing what this data is (and how it is supposed to be carried in RTP packets) we do not (and will not) proxy them. (The video and audio (if any) substreams, however, can be proxied just fine, provided that you use the latest version of the "LIVE555 Streaming Media" code.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 16 17:11:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jul 2012 17:11:03 -0700 Subject: [Live-devel] How to remove ServerMediaServer dynamically In-Reply-To: <1342345642.51211.YahooMailNeo@web15804.mail.cnb.yahoo.com> References: <1342345642.51211.YahooMailNeo@web15804.mail.cnb.yahoo.com> Message-ID: <3BADA453-1A9B-4FDB-A2D0-4B6FDD8CEBEC@live555.com> > I am using live555 media server. I am trying to remove media by calling RTSPServer::removeServerMediaSession(session); The code for "LIVE555 Media Server" application is not intended to be modified (especially by casual hobbyists). (Note that the "LIVE555 Media Server" will remove "ServerMediaSession" objects automatically if you remove its underlying file, so you shouldn't need to modify the server's code to do this.) Instead, you should develop your own server application (perhaps using the "testOnDemandRTSPServer" demo application). > This media is created by calling RTSPServer::addServerMediaSession(session); The problem is live555 server will complain "BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor" then abort immediately. Sorry, but I can't explain this (and because you have modified the code, I can't help you here). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From techvalens.testing at gmail.com Mon Jul 16 03:22:38 2012 From: techvalens.testing at gmail.com (techvalens testing) Date: Mon, 16 Jul 2012 15:52:38 +0530 Subject: [Live-devel] How to integrate LIVE555 Streaming Media for OpenRTSP into my Android Application Message-ID: Hi, I want to use this code into my Android application, please suggest me how to integrate this code into my application or can i use it as library in application if yes then how ? And also how to Compile and Run this Code. can anyone guide me that how i used this code for OpenRTSP. Thank & Regards Techvalens Testing -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhg84 at gmail.com Mon Jul 16 04:27:12 2012 From: saurabhg84 at gmail.com (Saurabh Gandhi) Date: Mon, 16 Jul 2012 16:57:12 +0530 Subject: [Live-devel] OpenRTSP Qt integration for video rendering Message-ID: Hello everyone, I was trying to use Qt for playing live video for which Qt provides a phonon class. However, the limitation with this is that it is not capable of decoding RTSP packets on windows (since phonon uses Directshow on windows platform). In order to make it capable of doing this, I am planning to now integrate openRTSP with Qt. Within openRTSP where can I find a pointer / handle to the video buffer or frame buffer so that I can pass on this to my Qt widget for display. Has anyone attempted this before? Any pointers on the correct approach for doing this would be highly appreciated. Thanks in advance. -- Regards, Saurabh Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbatra18 at gmail.com Mon Jul 16 04:53:57 2012 From: tbatra18 at gmail.com (Tarun Batra) Date: Mon, 16 Jul 2012 17:23:57 +0530 Subject: [Live-devel] bit rate whether i am correct, it is bit rate or byte rate Message-ID: Hello sir I did the following method to find the Kilo bits per second RTPSink* videoSink; int64_t uSecsToDelay=2000000; int64_t uSecsToDelay2=1000000; void play(); // forward void periodicQOSMeasurement1(void* clientData);//actually bit rate mesaurement void periodicQOSMeasurement2(void* clientData); int CreateINI(); char *sstreamip; int SSport; int s21; int o21; int s1,o1,s2,o2; int main() { ..... ....... } void play() { unsigned const inputDataChunkSize = TRANSPORT_PACKETS_PER_NETWORK_PACKET*TRANSPORT_PACKET_SIZE; // Open the input file as a 'byte-stream file source': ByteStreamFileSource* fileSource = ByteStreamFileSource::createNew(*env, inputFileName, inputDataChunkSize); if (fileSource == NULL) { *env << "Unable to open file \"" << inputFileName << "\" as a byte-stream file source\n"; exit(1); } // Create a 'framer' for the input source (to give us proper inter-packet gaps): videoSource = MPEG2TransportStreamFramer::createNew(*env, fileSource); // Finally, start playing: *env << "Beginning to read from file...\n"; videoSink->startPlaying(*videoSource, afterPlaying, videoSink); env->taskScheduler().scheduleDelayedTask(uSecsToDelay, (TaskFunc*)periodicQOSMeasurement1, videoSink); } void periodicQOSMeasurement1(void* clientData) {struct timeval timeNow; int64_t uSecsToDelay1=1000000; RTPSink* sink = (RTPSink*)clientData; gettimeofday(&timeNow, NULL); s1=timeNow.tv_sec; printf("value of s1 %d\n",s1); o1= videoSink->octetCount(); printf("value of o1 %d\n",o1); env->taskScheduler().scheduleDelayedTask(uSecsToDelay1, (TaskFunc*)periodicQOSMeasurement2,sink); } void periodicQOSMeasurement2(void* clientData) { struct timeval timeNow; RTPSink* sink = (RTPSink*)clientData; gettimeofday(&timeNow, NULL); s2=timeNow.tv_sec; printf("value of s2 %d\n",s2); o2= videoSink->octetCount(); printf("value of o2 %d\n",o2); float mbits_sent = (o2 - o1) / 1024.0/ (s2 - s1); printf("mbits_sent is %f\n",mbits_sent); env->taskScheduler().scheduleDelayedTask(uSecsToDelay2, (TaskFunc*)periodicQOSMeasurement1,sink); } *Ross i am having 2 ques now* *1>whether it will be kilo bits per second or kilo bytes per second?* *2>for the same file i am getting streaming bit/byte rate of 24.565 and 25.365 and if i stream the same file using vlc i am getting stream bit rate always above 100Kb/s, i am streaming the file given by you "bipbop-gear1-all.ts". * -------------- next part -------------- An HTML attachment was scrubbed... URL: From avishic at gmail.com Mon Jul 16 08:33:37 2012 From: avishic at gmail.com (Avishay Cohen) Date: Mon, 16 Jul 2012 18:33:37 +0300 Subject: [Live-devel] How can i use Live555 to stream Client -> Server ? Message-ID: Hi, I want to use Live555 in order to stream media from the iPhone camera to the server, using RTSP/RTP. I've seen that other clients using [Announce+DSP], [Setup] and [Record] to do that. It seems from the code of MediaSession & ServerMediaSession, that client cannot stream to server. Should i implement a MediaSession subclass for that? or is there an easier way? Also i've seen that there is a boolean "streamOutgoing" in 'Setup' that seems to be there for that purpose, but no example for using it. Thanks for your help! Avishay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.longney at logica.com Mon Jul 16 18:18:01 2012 From: ian.longney at logica.com (Longney, Ian) Date: Tue, 17 Jul 2012 11:18:01 +1000 Subject: [Live-devel] Issue with proxyserver and multiple clients Message-ID: > As stated (in boldface) on our web page: If you are having trouble with the proxy server, then we recommend using the "-V" option to try to figure out what's wrong. > >Also, I suggest running "testRTSPClient" (rather than VLC or QuickTime Player) as your RTSP client, at least initially, to help figure out what's happening. >It would also be useful to know if the problem that you're seeing (with the first client 'freezing' when the second client connects) happens when the two clients are running on different computers, or only if the two clients are running on the same computer. I have run the testRTSPClient for 2 clients and attached the output below. Client2 was started around 10 seconds after the first. I have also included the output from the proxyserver (run with the -V option). The client 'freezing' problem occurs in both cases (ie when running from the same host and running on different hosts). I have more tracing output but couldn't send more through due to the 80kb email limit. I have included the text directly into the email - is it OK to send trace information as attachments in future? ------------------------------------------------------------------------ -------------------------------------------------------------- Proxyserver output LIVE555 Proxy Server (LIVE555 Streaming Media library version 2012.07.06) Opening connection to 128.129.224.36, port 554... RTSP stream, proxying the stream "rtsp://128.129.224.36/live2.sdp" Play this stream using the URL "rtsp://128.129.224.101/proxyStream" (We use port 8000 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://128.129.224.36/live2.sdp RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.06) Accept: application/sdp Received 490 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Tue, 1 Jan 2000 1:41:27 GMT Content-Base: rtsp://128.129.224.36/live2.sdp/ Content-Type: application/sdp Content-Length: 327 v=0 o=RTSP 949369287 376 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=2 a=fmtp:98 packetization-mode=1; profile-level-id=4d001f; sprop-parameter-sets=Z00AH9oCgPZA,aO48gA== ProxyServerMediaSession["rtsp://128.129.224.36/live2.sdp/"] added new "ProxyServerMediaSubsession" for RTP/video/H264 track accept()ed connection from 128.129.224.101 Liveness indication from client at 128.129.224.101 Liveness indication from client at 128.129.224.101 RTSPClientSession[00813FE8]::handleRequestBytes() read 168 new bytes:DESCRIBE rtsp://128.129.224.101/proxyStream RTSP/1.0 CSeq: 2 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Accept: application/sdp parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "proxyStream", CSeq "2", Content-Length 0, with 0 bytes f ollowing the message. ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) RTCPInstance[0025E048]::RTCPInstance() schedule(2.170003->1342422818.399853) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() sending response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 16 2012 07:13:36 GMT Content-Base: rtsp://128.129.224.101/proxyStream/ Content-Type: application/sdp Content-Length: 524 v=0 o=- 1342422799978566 1 IN IP4 128.129.224.101 s=LIVE555 Streaming Media v2012.07.06 i=LIVE555 Streaming Media v2012.07.06 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.07.06 a=x-qt-text-inf:LIVE555 Streaming Media v2012.07.06 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=4D001F;sprop-parameter-sets=Z00AH9 oCgPZA,aO48gA== a=control:track1 Liveness indication from client at 128.129.224.101 RTSPClientSession[00813FE8]::handleRequestBytes() read 199 new bytes:SETUP rtsp://128.129.224.101/proxyStream/track1 RTSP/1.0 CSeq: 3 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Transport: RTP/AVP;unicast;client_port=61696-61697 parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "proxyStream", urlSuffix "track1", CSeq "3", Content-Length 0, with 0 byte s following the message. ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 1915308469) Sending request: SETUP rtsp://128.129.224.36/live2.sdp/trackID=2 RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.06) Transport: RTP/AVP;unicast;client_port=61692-61693 ProxyServerMediaSubsession["H264"]::createNewRTPSink() sending response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 16 2012 07:13:36 GMT Transport: RTP/AVP;unicast;destination=128.129.224.101;source=128.129.224.101;clien t_port=61696-61697;server_port=6970-6971 Session: 722949B5 Received 166 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Tue, 1 Jan 2000 1:41:43 GMT Session: 1794250;timeout=80 Transport: RTP/AVP;unicast;client_port=61692-61693;server_port=5556-5557 ProxyRTSPClient["rtsp://128.129.224.36/live2.sdp/"]::continueAfterSETUP( ): head codec: H264; numSubsessions 1 queue: H264 Sending request: PLAY rtsp://128.129.224.36/live2.sdp/ RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.06) Session: 1794250 Received 200 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Tue, 1 Jan 2000 1:41:43 GMT Session: 1794250;timeout=80 RTP-Info: url=rtsp://128.129.224.36/live2.sdp/trackID=2;seq=0;rtptime=0 Range: npt=0- RTCP-Interval: 250 Liveness indication from client at 128.129.224.101 RTSPClientSession[00813FE8]::handleRequestBytes() read 178 new bytes:PLAY rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 4 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Session: 722949B5 Range: npt=0.000- parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "proxyStream", urlSuffix "", CSeq "4", Content-Length 0, with 0 bytes follo wing the message. RTCPInstance[0025FD70]::RTCPInstance() schedule(1.309813->1342422817.651552) sending response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 16 2012 07:13:36 GMT Range: npt=0.000- Session: 722949B5 RTP-Info: url=rtsp://128.129.224.101/proxyStream/track1;seq=13062;rtptime=11176070 36 [0025E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 001b60cd bc40b857 e7ae1400 00004650 00000002 00008e52 81ca0008 001b60cd 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x001b60cd UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x001b60cd validated entire RTCP packet [0025E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 001b60cd bc40b858 4e147800 0000d2f0 00000004 00011519 81ca0008 001b60cd 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x001b60cd UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x001b60cd validated entire RTCP packet schedule(0.346243->1342422817.998475) schedule(0.744794->1342422818.744019) sending REPORT sending RTCP packet 81c90007 f2f13eb8 001b60cd 00ffffff 00010084 00000077 b8584e14 00012afa 81ca0005 f2f13eb8 010d4155 2d4c3242 31333530 34334800 schedule(2.284175->1342422820.689017) schedule(0.167721->1342422818.911987) schedule(0.024838->1342422818.937176) sending REPORT sending RTCP packet 80c80006 8c14dd48 d3ae3da2 f0743201 42a0c669 000000af 00036160 81ca0005 8c14dd48 010d4155 2d4c3242 31333530 34334800 schedule(3.063098->1342422822.007421) [0025FD70]saw incoming RTCP packet (from address 128.129.224.101, port 61697) 81c90007 e8cd4ffc 8c14dd48 00ffffff 000133cc 02843aec 3da2f074 00004ba3 81ca0005 e8cd4ffc 010d4155 2d4c3242 31333530 34334800 RR Adding new entry for SSRC e8cd4ffc in RTPTransmissionStatsDB RTCP RR data (received at 1342422819.260161): lossStats 0x00ffffff, lastPacketNumReceived 0x000133cc, jitter 0x02843aec, lastSRTime 0x3da2f074, diffSR _RRTime 0x00004ba3 => round-trip delay: 0x0683 (== 0.025436 seconds) Liveness indication from client at 128.129.224.101 validated RTCP subpacket (type 2): 1, 201, 0, 0xe8cd4ffc UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xe8cd4ffc validated entire RTCP packet schedule(3.303296->1342422823.993725) sending REPORT sending RTCP packet 80c80006 8c14dd48 d3ae3da6 023c9689 42a4fd84 0000016e 00070fa3 81ca0005 8c14dd48 010d4155 2d4c3242 31333530 34334800 schedule(3.930149->1342422825.943620) sending REPORT sending RTCP packet 81c90007 f2f13eb8 001b60cd 00ffffff 000101f1 0000008d b8584e14 0006c2e5 81ca0005 f2f13eb8 010d4155 2d4c3242 31333530 34334800 schedule(6.138819->1342422830.137994) [0025E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 001b60cd bc40b85f 8b020c00 000ac38c 00000028 000a16c3 81ca0008 001b60cd 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x001b60cd UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x001b60cd validated entire RTCP packet [0025FD70]saw incoming RTCP packet (from address 128.129.224.101, port 61697) 81c90007 e8cd4ffc 8c14dd48 00ffffff 00013551 005cefc1 3da6023c 00035c99 81ca0005 e8cd4ffc 010d4155 2d4c3242 31333530 34334800 RR RTCP RR data (received at 1342422825.395279): lossStats 0x00ffffff, lastPacketNumReceived 0x00013551, jitter 0x005cefc1, lastSRTime 0x3da6023c, diffSR _RRTime 0x00035c99 => round-trip delay: 0x065c (== 0.024841 seconds) Liveness indication from client at 128.129.224.101 validated RTCP subpacket (type 2): 1, 201, 0, 0xe8cd4ffc UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xe8cd4ffc validated entire RTCP packet schedule(1.403613->1342422827.349193) accept()ed connection from 128.129.224.101 Liveness indication from client at 128.129.224.101 Liveness indication from client at 128.129.224.101 RTSPClientSession[0081DD28]::handleRequestBytes() read 168 new bytes:DESCRIBE rtsp://128.129.224.101/proxyStream RTSP/1.0 CSeq: 2 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Accept: application/sdp RTSP client1 output ------------------------------------------------------------------------ -------------------------------------------------------------- Opening connection to 128.129.224.101, port 554... ...remote connection opened Sending request: DESCRIBE rtsp://128.129.224.101/proxyStream RTSP/1.0 CSeq: 2 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Accept: application/sdp Received 692 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 16 2012 07:13:36 GMT Content-Base: rtsp://128.129.224.101/proxyStream/ Content-Type: application/sdp Content-Length: 524 v=0 o=- 1342422799978566 1 IN IP4 128.129.224.101 s=LIVE555 Streaming Media v2012.07.06 i=LIVE555 Streaming Media v2012.07.06 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.07.06 a=x-qt-text-inf:LIVE555 Streaming Media v2012.07.06 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=4D001F;sprop-parameter-sets=Z00AH9 oCgPZA,aO48gA== a=control:track1 [URL:"rtsp://128.129.224.101/proxyStream/"]: Got a SDP description: v=0 o=- 1342422799978566 1 IN IP4 128.129.224.101 s=LIVE555 Streaming Media v2012.07.06 i=LIVE555 Streaming Media v2012.07.06 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.07.06 a=x-qt-text-inf:LIVE555 Streaming Media v2012.07.06 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=4D001F;sprop-parameter-sets=Z00AH9 oCgPZA,aO48gA== a=control:track1 RTCPInstance[003A5D48]::RTCPInstance() schedule(2.950770->1342422819.245959) [URL:"rtsp://128.129.224.101/proxyStream/"]: Initiated the "video/H264" subsession (client ports 61696-61697) Sending request: SETUP rtsp://128.129.224.101/proxyStream/track1 RTSP/1.0 CSeq: 3 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Transport: RTP/AVP;unicast;client_port=61696-61697 Received 209 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 16 2012 07:13:36 GMT Transport: RTP/AVP;unicast;destination=128.129.224.101;source=128.129.224.101;clien t_port=61696-61697;server_p ort=6970-6971 Session: 722949B5 [URL:"rtsp://128.129.224.101/proxyStream/"]: Set up the "video/H264" subsession (client ports 61696-61697) [URL:"rtsp://128.129.224.101/proxyStream/"]: Created a data sink for the "video/H264" subsession Sending request: PLAY rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 4 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Session: 722949B5 Range: npt=0.000- Received 189 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 16 2012 07:13:36 GMT Range: npt=0.000- Session: 722949B5 RTP-Info: url=rtsp://128.129.224.101/proxyStream/track1;seq=13062;rtptime=11176070 36 [URL:"rtsp://128.129.224.101/proxyStream/"]: Started playing session... Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2422816.430126! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2422816.430126! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24912 bytes. Presentation time: 134 2422816.430126! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 11123 bytes. Presentation time: 134 2422816.630126! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406533.547282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406533.547282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24992 bytes. Presentation time: 134 2406533.547282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9126 bytes. Presentation time: 134 2406533.747282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406533.947282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406533.947282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 25035 bytes. Presentation time: 134 2406533.947282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 8195 bytes. Presentation time: 134 2406534.147282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406534.347282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406534.347282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24846 bytes. Presentation time: 134 2406534.347282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 7000 bytes. Presentation time: 134 2406534.547282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406534.747282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406534.747282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24877 bytes. Presentation time: 134 2406534.747282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 7032 bytes. Presentation time: 134 2406534.947282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406535.147282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406535.147282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24750 bytes. Presentation time: 134 2406535.147282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4383 bytes. Presentation time: 134 2406535.347282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406535.547282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406535.547282! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24865 bytes. Presentation time: 134 2406535.547282! [003A5D48]saw incoming RTCP packet (from address 128.129.224.101, port 6971) 80c80006 8c14dd48 d3ae3da2 f0743201 42a0c669 000000af 00036160 81ca0005 8c14dd48 010d4155 2d4c3242 31333530 3 4334800 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c14dd48 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x8c14dd48 validated entire RTCP packet Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4375 bytes. Presentation time: 134 2406535.747840 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406535.947840 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406535.947840 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24865 bytes. Presentation time: 134 2406535.947840 2406541.985849 RTSP client2 output ------------------------------------------------------------------------ -------------------------------------------------------------- Opening connection to 128.129.224.101, port 554... ...remote connection opened Sending request: DESCRIBE rtsp://128.129.224.101/proxyStream RTSP/1.0 CSeq: 2 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Accept: application/sdp Received 692 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 16 2012 07:13:46 GMT Content-Base: rtsp://128.129.224.101/proxyStream/ Content-Type: application/sdp Content-Length: 524 v=0 o=- 1342422799978566 1 IN IP4 128.129.224.101 s=LIVE555 Streaming Media v2012.07.06 i=LIVE555 Streaming Media v2012.07.06 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.07.06 a=x-qt-text-inf:LIVE555 Streaming Media v2012.07.06 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=4D001F;sprop-parameter-sets=Z00AH9 oCgPZA,aO48gA== a=control:track1 [URL:"rtsp://128.129.224.101/proxyStream/"]: Got a SDP description: v=0 o=- 1342422799978566 1 IN IP4 128.129.224.101 s=LIVE555 Streaming Media v2012.07.06 i=LIVE555 Streaming Media v2012.07.06 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.07.06 a=x-qt-text-inf:LIVE555 Streaming Media v2012.07.06 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=4D001F;sprop-parameter-sets=Z00AH9 oCgPZA,aO48gA== a=control:track1 RTCPInstance[00335D48]::RTCPInstance() schedule(1.948064->1342422828.808891) [URL:"rtsp://128.129.224.101/proxyStream/"]: Initiated the "video/H264" subsession (client ports 65436-65437) Sending request: SETUP rtsp://128.129.224.101/proxyStream/track1 RTSP/1.0 CSeq: 3 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Transport: RTP/AVP;unicast;client_port=65436-65437 Received 209 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 16 2012 07:13:46 GMT Transport: RTP/AVP;unicast;destination=128.129.224.101;source=128.129.224.101;clien t_port=65436-65437;server_p ort=6970-6971 Session: AFDB3EFC [URL:"rtsp://128.129.224.101/proxyStream/"]: Set up the "video/H264" subsession (client ports 65436-65437) [URL:"rtsp://128.129.224.101/proxyStream/"]: Created a data sink for the "video/H264" subsession Sending request: PLAY rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 4 User-Agent: D:\temp\testRTSPClient.exe (LIVE555 Streaming Media v2012.07.06) Session: AFDB3EFC Range: npt=0.000- Received 189 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 16 2012 07:13:46 GMT Range: npt=0.000- Session: AFDB3EFC RTP-Info: url=rtsp://128.129.224.101/proxyStream/track1;seq=13745;rtptime=11185474 22 [URL:"rtsp://128.129.224.101/proxyStream/"]: Started playing session... Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4168 bytes. Presentation time: 134 2422827.061730! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2422827.261730! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2422827.261730! Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24773 bytes. Presentation time: 134 2422827.261730! [00335D48]saw incoming RTCP packet (from address 128.129.224.101, port 6971) 80c80006 8c14dd48 d3ae3dab 599c065b 9a05c0c1 000002c2 000d920e 81ca0005 8c14dd48 010d4155 2d4c3242 31333530 3 4334800 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x8c14dd48 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x8c14dd48 validated entire RTCP packet Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 3874 bytes. Presentation time: 134 2406544.184849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406544.384849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406544.384849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24784 bytes. Presentation time: 134 2406544.384849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 10950 bytes. Presentation time: 134 2406544.584849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406544.784849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406544.784849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24977 bytes. Presentation time: 134 2406544.784849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 7915 bytes. Presentation time: 134 2406544.984849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 9 bytes. Presentation time: 134 2406545.184849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 4 bytes. Presentation time: 134 2406545.184849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 24904 bytes. Presentation time: 134 2406545.184849 Stream "rtsp://128.129.224.101/proxyStream/"; video/H264: Received 8306 bytes. Presentation time: 134 2406545.384849 Thanks Ian Longney | MOSAIC Product Centre Manager Ground Floor, 436 Elgar Road, Box Hill, VIC 3128 | Australia T: +61 3 9843 0661 | M: +61 412 279 861 ian.longney at logica.com | www.logica.com Logica Australia Pty Ltd - Registered in Australia (ABN 39 001 260 699) Registered Office: Level 13, 100 Pacific Highway, North Sydney, NSW 2060, Australia Ian Longney | MOSAIC Product Centre Manager Ground Floor, 436 Elgar Road, Box Hill, VIC 3128 | Australia T: +61 3 9843 0661 | M: +61 412 279 861 ian.longney at logica.com | www.logica.com Logica Australia Pty Ltd - Registered in Australia (ABN 39 001 260 699) Registered Office: Level 13, 100 Pacific Highway, North Sydney, NSW 2060, Australia Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 16 18:55:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jul 2012 18:55:47 -0700 Subject: [Live-devel] Issue with proxyserver and multiple clients In-Reply-To: References: Message-ID: <4B7B5876-6B8F-41D1-B686-6901E2D8AB45@live555.com> This is very strange. Unfortunately I can't explain why the first client would stop receiving data after the second client starts up, nor have I been able to reproduce this. I notice that - in the debugging output that you sent - the proxy server and both clients are all running on the same host (128.129.224.101). That should be OK (and it worked OK in my own testing), but I'm wondering if you get the same result if you run the two clients on a different host from the proxy server (or if you run client 1 on a different host from the proxy server, and run client 2 on a different host from both the proxy server and client 1)? What OS is your host 128.129.224.101 running? If you get the same result even when your clients are running on a different host from the proxy server, then please send the complete debugging output from your proxy server (but not from the clients this time). I say "complete" debugging output because last time you chopped off the output just at the point where the proxy server received the RTSP "DESCRIBE" command from the second client. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 16 23:33:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jul 2012 23:33:51 -0700 Subject: [Live-devel] How to integrate LIVE555 Streaming Media for OpenRTSP into my Android Application In-Reply-To: References: Message-ID: <51E01532-238C-4230-9ADE-2D2A9D808344@live555.com> > I want to use this code into my Android application, please suggest me how to integrate this code into my application As we clearly note in the "openRTSP" documentation (web page), and the "openRTSP" source code itself, we don't recommend using the "openRTSP" code as a model for your own RTSP client application. Instead, you should use the "testRTSPClient" application code as a model. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 16 23:50:40 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jul 2012 23:50:40 -0700 Subject: [Live-devel] OpenRTSP Qt integration for video rendering In-Reply-To: References: Message-ID: <41D4B040-9C36-46E4-87A0-76A0D1F51912@live555.com> As we clearly note in the "openRTSP" documentation (web page), and the "openRTSP" source code itself, we don't recommend using the "openRTSP" code as a model for your own RTSP client application. Instead, you should use the "testRTSPClient" application code as a model. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 16 23:56:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jul 2012 23:56:33 -0700 Subject: [Live-devel] How can i use Live555 to stream Client -> Server ? In-Reply-To: References: Message-ID: <7D80C968-B97E-4C55-AECC-B1A65DA57158@live555.com> "How can i use Live555 to stream Client -> Server ?" In short, you don't. Data sources - in particular network cameras - should be RTSP servers, which deliver data in response to requests by clients. If you want your camera (server) to deliver data to another server, then the way to do this is to make the second server a 'proxy' for the camera server. I.e., the proxy server appears as a server to external clients, but acts as a client for the camera server. Note, for example the "LIVE555 Proxy Server": http://www.live555.com/proxyServer/ > I've seen that other clients using [Announce+DSP], [Setup] and [Record] to do that. This is a non-standard (ab)use of the RTSP protocol, that's implemented by Apple's 'Darwin Streaming Servers', but not by our RTSP server implementation. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From techvalens.testing at gmail.com Tue Jul 17 00:41:18 2012 From: techvalens.testing at gmail.com (techvalens testing) Date: Tue, 17 Jul 2012 13:11:18 +0530 Subject: [Live-devel] How to integrate LIVE555 Streaming Media for OpenRTSP into my Android Application In-Reply-To: <51E01532-238C-4230-9ADE-2D2A9D808344@live555.com> References: <51E01532-238C-4230-9ADE-2D2A9D808344@live555.com> Message-ID: Hi, Thanks for reply. Can you please tell me that how to use testRTSPClient in our android application, i know that JNI is one solution. is there any wrapper around testRTSPClient that i can use. Please reply me as soon as possible. On Tue, Jul 17, 2012 at 12:03 PM, Ross Finlayson wrote: > I want to use this code into my Android application, please suggest me how > to integrate this code into my application > > > As we clearly note in the "openRTSP" documentation (web page), and the > "openRTSP" source code itself, we don't recommend using the "openRTSP" code > as a model for your own RTSP client application. Instead, you should use > the "testRTSPClient" application code as a model. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddugger at isdcam.com Tue Jul 17 09:30:01 2012 From: ddugger at isdcam.com (Dirk Dugger) Date: Tue, 17 Jul 2012 09:30:01 -0700 Subject: [Live-devel] send error callback Message-ID: Hi All, I saw that there was a patch a while back to register a send error callback - fOnSendErrorFunc/Data to deal with socket write errors (like from socket FIN/RST). I am currently streaming live using testOnDemandRTSPServer as a model. Where do I set that callback and how do I cleanly shut that session down? Is there an example somewhere of how to use this? I'm looking at the case where I'm streaming rtp/tcp and the socket closes without a TEARDOWN. Thanks, Dirk From sidprice at softtools.com Tue Jul 17 10:43:55 2012 From: sidprice at softtools.com (Sid Price) Date: Tue, 17 Jul 2012 11:43:55 -0600 Subject: [Live-devel] Some project organization advice Message-ID: <00fc01cd6443$be4baf70$3ae30e50$@softtools.com> Hi Ross, I am going to be moving forward with a couple of implementations using Live555 on embedded platforms using Windows Compact 7. My initial work required a lot of changes to deal with the fact that all the systems are headless and the printfs etc are not supported. As you know there are lots of places that report debug data by that method so I had updated the code to use the serial debug message port on the platform. Relaticley simple edits but lots of them. My question is how best to do these extensive changes so that going forward I can make easiest use of the trunk code as you update it? So far I think the only way is going to be by using some kind of diff/merge utility. Any other suggestions? Many thanks for you continued support of this valuable code base, Sid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bstump at codemass.com Tue Jul 17 11:15:21 2012 From: bstump at codemass.com (Barry Stump) Date: Tue, 17 Jul 2012 11:15:21 -0700 Subject: [Live-devel] Detecting socket close when receiving streams via TCP Message-ID: I am troubleshooting an issue similar to Dirk Dugger when receiving RTP over TCP via the RTSPClient class. If the server closes the connection mid stream, the client gets no notification. I have traced the problem to the readSocket() function in GroupsockHelper.cpp where recvfrom() is used to get data from the socket. On posix systems, recvfrom() should return the number of bytes read, or a negative number on error, or **zero if the connection is TCP and the peer has closed its half side of the connection**. It's this last check for zero that is missing, causing Live555 to continue checking the socket for new data even though it has been closed by the server. This problem can manifest both with RTP over TCP as well as the RTSP commands. If the server (or intermediary firewall) closes the socket without sending a RTSP response for example, the library will wait indefinitely for a response that never comes. Is there a simple way to add the check for zero for recvfrom() and bubble the message up through the library so that RTSPClients can be notified? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 17 13:27:31 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Jul 2012 13:27:31 -0700 Subject: [Live-devel] send error callback In-Reply-To: References: Message-ID: > I'm looking at the case where I'm streaming rtp/tcp and the socket closes without a TEARDOWN. In general it's a bad idea to complicate your application by trying to optimize the handling of an unusual situation. Especially because our server implementation already automatically handles this situation, by closing the connection and reclaims resources for inactive clients after "reclamationTestSeconds" seconds (default value: 65 seconds). (This also handles the situation where the client has 'died', even though the socket remains open.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 17 13:54:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Jul 2012 13:54:38 -0700 Subject: [Live-devel] Detecting socket close when receiving streams via TCP In-Reply-To: References: Message-ID: <1F5C5835-A07C-4253-A860-67917EFD990D@live555.com> > I am troubleshooting an issue similar to Dirk Dugger when receiving RTP over TCP via the RTSPClient class. If the server closes the connection mid stream, the client gets no notification. As I also said in response to Dirk's question: In general it's a bad idea to complicate your application by trying to optimize the handling of an unusual situation. This answer - to a similar question last month - outlines what I think is the best way to handle this situation (and other, more general situations): http://lists.live555.com/pipermail/live-devel/2012-June/015348.html However, concerning the specific problem that you referred to: > I have traced the problem to the readSocket() function in GroupsockHelper.cpp where recvfrom() is used to get data from the socket. On posix systems, recvfrom() should return the number of bytes read, or a negative number on error, or **zero if the connection is TCP and the peer has closed its half side of the connection**. I *might* be able to modify the "readSocket()" function to better handle this case, but I don't want to risk inadvertently messing up higher-level code that uses this function by mishandling cases when "recvfrom()" might return zero in a *non*-error situation. In the situation that you are concerned about - recvfrom() returning "zero if the connection is TCP and the peer has closed its half side of the connection" - what is the value of "errno" in this case? (If it's something non-zero, then I should be able to update "readSocket()" to add a test for this.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 17 14:17:46 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Jul 2012 14:17:46 -0700 Subject: [Live-devel] Some project organization advice In-Reply-To: <00fc01cd6443$be4baf70$3ae30e50$@softtools.com> References: <00fc01cd6443$be4baf70$3ae30e50$@softtools.com> Message-ID: <1FE2498B-A4A3-4F1A-AE00-5512ACE09837@live555.com> > I am going to be moving forward with a couple of implementations using Live555 on embedded platforms using Windows Compact 7. My initial work required a lot of changes to deal with the fact that all the systems are headless and the printfs etc are not supported. In short, if you can't use our code without making a lot of changes to it, then you probably shouldn't be using it. (As you know, you can't expect any support once you've made changes to the supplied code.) Perhaps you should try to find some other code that's specifically designed to work with 'Windows Compact 7'? However, I'm not convinced that you need to make "a lot of changes" to the code. For starters, if your system doesn't have "fprintf()", then why not just implement your own version. Also, you can write your own "UsageEnvironment" subclass that redefines the "<<" operators. (This sort of thing is one of the main purposes of the "UsageEnvironment" abstract base class.) However, there's a bigger issue here: I think you should reevaluate your decision to use Windows as the OS for your embedded system. I can understand people still using Windows for desktop PCs (due to its large installed base there). But I simply don't understand why, in this day and age, anyone would want to use Windows for an embedded system. In today's world, Windows is becoming increasingly irrelevant, especially for embedded systems, where almost all of the 'top tier' developers are using Unix-based systems (including Linux, iOS, etc.). If you start developing embedded systems software for Windows, you're going to find yourself in a declining environment dominated by second-rate people, IMHO... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Tue Jul 17 14:40:08 2012 From: sidprice at softtools.com (Sid Price) Date: Tue, 17 Jul 2012 15:40:08 -0600 Subject: [Live-devel] Some project organization advice In-Reply-To: <1FE2498B-A4A3-4F1A-AE00-5512ACE09837@live555.com> References: <00fc01cd6443$be4baf70$3ae30e50$@softtools.com> <1FE2498B-A4A3-4F1A-AE00-5512ACE09837@live555.com> Message-ID: <017c01cd6464$be1be9e0$3a53bda0$@softtools.com> Ross, I am not going to debate whether I should be using Windows Compact 7 or not, that is a totally different issue. We should set that discussion aside. Now your suggestion of writing a new fprintf or other required functions makes very much sense and it is the path I will investigate. Also, your suggestion of sub classing the UsageEnvironment class also sounds like a good approach. Once again, thank you for the input, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, July 17, 2012 3:18 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Some project organization advice I am going to be moving forward with a couple of implementations using Live555 on embedded platforms using Windows Compact 7. My initial work required a lot of changes to deal with the fact that all the systems are headless and the printfs etc are not supported. In short, if you can't use our code without making a lot of changes to it, then you probably shouldn't be using it. (As you know, you can't expect any support once you've made changes to the supplied code.) Perhaps you should try to find some other code that's specifically designed to work with 'Windows Compact 7'? However, I'm not convinced that you need to make "a lot of changes" to the code. For starters, if your system doesn't have "fprintf()", then why not just implement your own version. Also, you can write your own "UsageEnvironment" subclass that redefines the "<<" operators. (This sort of thing is one of the main purposes of the "UsageEnvironment" abstract base class.) However, there's a bigger issue here: I think you should reevaluate your decision to use Windows as the OS for your embedded system. I can understand people still using Windows for desktop PCs (due to its large installed base there). But I simply don't understand why, in this day and age, anyone would want to use Windows for an embedded system. In today's world, Windows is becoming increasingly irrelevant, especially for embedded systems, where almost all of the 'top tier' developers are using Unix-based systems (including Linux, iOS, etc.). If you start developing embedded systems software for Windows, you're going to find yourself in a declining environment dominated by second-rate people, IMHO... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.orry at gmail.com Tue Jul 17 02:55:00 2012 From: lionel.orry at gmail.com (Lionel Orry) Date: Tue, 17 Jul 2012 11:55:00 +0200 Subject: [Live-devel] Enhancements in some RTSP fields detection Message-ID: Hello, please find attached a patch to improve the parsing/detection of some RTSP fields to attempt to be closer to the behaviour expected by the RFC. Thank you for your comments about it. With kind regards, Lionel -------------- next part -------------- A non-text attachment was scrubbed... Name: live555_enhance_rtsp_fields.patch Type: application/octet-stream Size: 3372 bytes Desc: not available URL: From finlayson at live555.com Tue Jul 17 15:10:30 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Jul 2012 15:10:30 -0700 Subject: [Live-devel] Enhancements in some RTSP fields detection In-Reply-To: References: Message-ID: <4596D15B-7785-4164-B9FA-38126E08C490@live555.com> > please find attached a patch to improve the parsing/detection of some > RTSP fields to attempt to be closer to the behaviour expected by the > RFC. OK, thanks. This change will be included in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ketangholap1990 at gmail.com Tue Jul 17 03:17:17 2012 From: ketangholap1990 at gmail.com (Ketan Gholap) Date: Tue, 17 Jul 2012 15:47:17 +0530 Subject: [Live-devel] MPEG1or2VideoStreamDiscreteFramer frame rate Message-ID: *Hello Sir I do in a need to find out the frame rate in a live media server and i made an application in which i am using video source:- videoSource = MPEG1or2VideoStreamDiscreteFramer::createNew(*env, videoES); Please explain some what how to calculate frame rate in **MPEG1or2VideoStreamDiscreteFramer, any sample would be great help. Thanks * -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglan at yahoo.com Tue Jul 17 03:43:00 2012 From: zanglan at yahoo.com (Lan Zang) Date: Tue, 17 Jul 2012 18:43:00 +0800 (CST) Subject: [Live-devel] How to remove ServerMediaServer dynamically In-Reply-To: <3BADA453-1A9B-4FDB-A2D0-4B6FDD8CEBEC@live555.com> References: <1342345642.51211.YahooMailNeo@web15804.mail.cnb.yahoo.com> <3BADA453-1A9B-4FDB-A2D0-4B6FDD8CEBEC@live555.com> Message-ID: <1342521780.46655.YahooMailNeo@web15803.mail.cnb.yahoo.com> Hi,? Thanks for your quick response. I think I might not state my question very clearly. I am working on a solution to add or remove the stream dynamically. I studied the codes in DynamicRTSPServer.cpp too.? My codes are rather simple. In some time point, I use RTSPServer::addServerMediaSession() to add the new created?MPEG2TransportUDPServerMediaSubsession?instance by?static method CreateNew(). And after a period of time, I use RTSPServer::removeServerMediaSession() to remove this stream session. The odd things are although both add/remove function finished successfully, there is no RTP data received from player even RTSP commands return 200OK. Which I doubt that the data sent to the RTPSource is not correctly received. ?There is another strange thing is mentioned below, although?removeServerMediaSession() return successfully, once player disconnects, my server complains "BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor" and failed. I used to write a similar server process, which uses?addServerMediaSession() to add a session at the beginning. That server process works fine. So,??I am wandering is that because there might be some RTP/RTCP sockets not cleared in the?BasicTaskScheduler::fReadSet. But I don't know how to identify it. Hope if you can shed any light on that to me? Regards, Lan Zang(Sander) ________________________________ From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Tuesday, July 17, 2012 8:11 AM Subject: Re: [Live-devel] How to remove ServerMediaServer dynamically I am using live555 media server. I am trying to remove media by calling RTSPServer::removeServerMediaSession(session); The code for "LIVE555 Media Server" application is not intended to be modified (especially by casual hobbyists). ?(Note that the "LIVE555 Media Server" will remove "ServerMediaSession" objects automatically if you remove its underlying file, so you shouldn't need to modify the server's code to do this.) Instead, you should develop your own server application (perhaps using the "testOnDemandRTSPServer" demo application). This media is created by calling RTSPServer::addServerMediaSession(session); The problem is live555 server will complain "BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor" then abort immediately.? Sorry, but I can't explain this (and because you have modified the code, I can't help you here). 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 frank at cyberdev.com Tue Jul 17 21:21:05 2012 From: frank at cyberdev.com (Frank Vernon) Date: Tue, 17 Jul 2012 22:21:05 -0600 Subject: [Live-devel] Using MPEG4GenericRTPSink for AAC on client? Message-ID: <2498FFE0-A227-482C-B950-4C877B532D82@cyberdev.com> Hi list- I feel like this is likely a newbie question, so my apologies in advance. I did read the FAQ and search the email archive first, I promise. I am attempting to receive and play AAC encoded audio from a webcam via RTSP. I have successfully done this for uLaw encoded audio using a custom MediaSink subclass class modeled heavily on the testRTSPClient.cpp example. How do I do this for AAC encoded audio? Apparently it's not as simple as grabbing the AAC encoded data the same way I did for the uLaw encoded data in my afterGettingFrame callback. In my digging around it would appear that I may need to use the MPEG4GenericRTPSink in order access the AAC data parsed to AAC frames. Is this true? If so, is it as simple as subclassing MPEG4GenericRTPSink? Where do I hook into this process in my subclass to gain access to the data I need to feed my AAC playback system? Are there any examples of using this class as a client? All of the examples I could find were for server side streaming. Thanks- Frank Vernon From ddugger at isdcam.com Tue Jul 17 22:32:20 2012 From: ddugger at isdcam.com (Dirk Dugger) Date: Tue, 17 Jul 2012 22:32:20 -0700 Subject: [Live-devel] send error callback Message-ID: Ross Says: > I'm looking at the case where I'm streaming rtp/tcp and the socket closes without a TEARDOWN. In general it's a bad idea to complicate your application by trying to optimize the handling of an unusual situation. Especially because our server implementation already automatically handles this situation, by closing the connection and reclaims resources for inactive clients after "reclamationTestSeconds" seconds (default value: 65 seconds). (This also handles the situation where the client has 'died', even though the socket remains open.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ ------------------------- Unfortunately I'm dealing with a client which does not send receiver reports, or any other indication which will update my liveness, so I have to DISABLE the liveness task. Furthermore, when the client closes, it doesn't TEARDOWN - it just FINs. So when that happens my CPU spikes since the rtsp server is going insane and will NEVER clean up. What I want is RTSPServer to behave like the inactivity timer went off when it detects a write error on the TCP socket. This is what I don't know how to do. It is not an option to make the client behave nicely. Thanks, Dirk From finlayson at live555.com Tue Jul 17 22:40:49 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Jul 2012 22:40:49 -0700 Subject: [Live-devel] Using MPEG4GenericRTPSink for AAC on client? In-Reply-To: <2498FFE0-A227-482C-B950-4C877B532D82@cyberdev.com> References: <2498FFE0-A227-482C-B950-4C877B532D82@cyberdev.com> Message-ID: > I am attempting to receive and play AAC encoded audio from a webcam via RTSP. I have successfully done this for uLaw encoded audio using a custom MediaSink subclass class modeled heavily on the testRTSPClient.cpp example. > > How do I do this for AAC encoded audio? Apparently it's not as simple as grabbing the AAC encoded data the same way I did for the uLaw encoded data in my afterGettingFrame callback. It actually is. Each chunk of data that's received by your "RTPSource" object (in this case, it will be a "MPEG4GenericRTPSource" object, but you shouldn't have to care about that, because it gets created automatically by the RTSP client code) should be a single (and complete) AAC audio frame. You will then feed each such frame to your decoder. The only tricky thing is that you (probably) will also need to pass 'configuration' data to your decoder, in order for it to be able to successfully decode the stream. This configuration data is derived from the stream's 'configuration string', which you (the client) can access by calling "MediaSubsession::fmtp_config()". You will probably then need to decode this string into binary form by calling "parseGeneralConfigStr()" on it. The resulting binary data will probably need to be input to your decoder. > In my digging around it would appear that I may need to use the MPEG4GenericRTPSink No! "RTPSink"s (and their subclasses) are used only for *transmitting* RTP packets, not for receiving them. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 17 23:03:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Jul 2012 23:03:20 -0700 Subject: [Live-devel] send error callback In-Reply-To: References: Message-ID: > What I want is RTSPServer to behave like the inactivity timer went off when it detects a write error on the TCP socket. Unfortunately I don't know of a way to do this. > It is not an option to make the client behave nicely. Well then that's too bad, because I have zero interest in supporting woefully non-standards-compliant clients like this (i.e., clients that don't send any periodic liveness indication, and don't use "TEARDOWN"). Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.orry at em-sys.fr Wed Jul 18 00:02:37 2012 From: lionel.orry at em-sys.fr (Lionel Orry) Date: Wed, 18 Jul 2012 09:02:37 +0200 Subject: [Live-devel] Enhancements in some RTSP fields detection In-Reply-To: <4596D15B-7785-4164-B9FA-38126E08C490@live555.com> References: <4596D15B-7785-4164-B9FA-38126E08C490@live555.com> Message-ID: <1342594957.16925.5.camel@localhost.localdomain> On Tue, 2012-07-17 at 15:10 -0700, Ross Finlayson wrote: > > please find attached a patch to improve the parsing/detection of > > some > > RTSP fields to attempt to be closer to the behaviour expected by the > > RFC. > > > > > OK, thanks. This change will be included in the next release of the > software. Thank you very much for your concern! I am also very interested in the resolution of the issue regarding independence of RTSP sessions wrt TCP connections, as described by Ralf Globisch earlier this month. If the resolution takes a lot of time (which I believe it does since it would need quite some changes), I would be glad to get some guidelines about how to start implementing a workaround (I am currently subclassing RTSPServerSupportingHTTPStreaming and RTSPClientSession). Best regards, Lionel Orry > > > 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 Wed Jul 18 00:17:35 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jul 2012 00:17:35 -0700 Subject: [Live-devel] Enhancements in some RTSP fields detection In-Reply-To: <1342594957.16925.5.camel@localhost.localdomain> References: <4596D15B-7785-4164-B9FA-38126E08C490@live555.com> <1342594957.16925.5.camel@localhost.localdomain> Message-ID: <5A49B841-1126-48A1-BE6D-17AA96A53CD1@live555.com> > I am also very interested in the resolution of the issue regarding > independence of RTSP sessions wrt TCP connections, as described by Ralf > Globisch earlier this month. This is a high-priority issue for me also, and it will be fixed soon. Stay tuned... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chao.yuan at alcatel-lucent.com Wed Jul 18 03:32:13 2012 From: chao.yuan at alcatel-lucent.com (Yuan, Chao (Chao)** CTR **) Date: Wed, 18 Jul 2012 12:32:13 +0200 Subject: [Live-devel] save the live video to local video Message-ID: <5FD979BDF2350C4796619C0AC619B38802F113DF3A@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> Hi,all One phone (we can call phone A) send live ts packets to live555 server, phone B can play the live ts packets form the live555 server, On the server, live555 can save the ts packets that from phone A to a local file: test.ts With the help of Ross, I use a StreamReplicator, class modifiedMPEG2TransportUDPServerMediaSubsession: public MPEG2TransportUDPServerMediaSubsession, do some change on : createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate){ FramedSource* inputSource = MPEG2TransportUDPServerMediaSubsession:: createNewStreamSource(clientSessionId, estBitrate); // call the parent class's implementation first StreamReplicator* replicator = StreamReplicator::createNew(envir(), inputSource); envir()<<"start to test.ts"; startReplicaFileSink(replicator, "test.ts"); } Howerver, for example, phone A start to live at time 00:00:00, phone B start to play the video at 00:10:00, that cause the test.ts file only save the ts packets from 00:10:00, the before 10 minites packets lost, This is not I wanted. How can I save the live ts packets at the right begin time? Another problem: And if I deleted the test.ts, then phone A start to live, phone B start to play, the ts packets will not saved, that is to say, no test.ts file! Why? BR, Chao, Yuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.orry at em-sys.fr Wed Jul 18 04:00:23 2012 From: lionel.orry at em-sys.fr (Lionel Orry) Date: Wed, 18 Jul 2012 13:00:23 +0200 Subject: [Live-devel] Add 454 (Session Not Found) handler to RTSPServer Message-ID: <1342609223.16925.17.camel@localhost.localdomain> Hi list, here is a patch suggesting the addition of a handler for the RTSP/1.0 454 status code. I've also replaced the '405 Not Allowed' response on a missing media session by this one which seems more appropriate in this case. Remark: it may be interesting to validate at the beginning of RTSPServer::RTSPClientSession::handleCmd_withinSession() the presence of the "Session" header field, and systematically return 454 in case of absence or unknown Session, what do you think? Is this too strict for some famous RTSP clients? Best regards, Lionel Orry -------------- next part -------------- A non-text attachment was scrubbed... Name: live555_add_454_handler.patch Type: text/x-patch Size: 2255 bytes Desc: not available URL: From johnx.mcnamara at intel.com Wed Jul 18 06:31:37 2012 From: johnx.mcnamara at intel.com (Mcnamara, JohnX) Date: Wed, 18 Jul 2012 13:31:37 +0000 Subject: [Live-devel] Issue converting H.264 with EOS NALU to MPEG-TS Message-ID: Hi Ross, Following on from an earlier post in relation to H264VideoStreamParser: http://lists.live555.com/pipermail/live-devel/2012-June/015350.html The fix provided worked for all the cases that I tested at the time but I recently encountered some other files where the H.264 stream was truncated in the MPEG-TS container when using H264VideoStreamFramer and MPEG2TransportStreamFromESSource. The files in question had an end_of_stream NAL Unit of 0x0000010b. This is a valid nal_unit_type according to Section 7.4.1, "NAL unit semantics", of the H.264 specification. You can reproduce the issue as follows with your sample tc10.264 file: cd testProgs cp ~/Videos/tc10.264 in.264 # Convert in.264 to out.ts: ./testH264VideoToTransportStream # Demux it back to H.264: ffmpeg -i out.ts -vcodec copy demuxed01.h264 # Verify that the files are the same: cmp in.264 demuxed01.h264 # Add the end of stream NALU to in the input file: perl -i -0777 -ne 'print $_, pack "N", 0x0000010b if eof' in.264 # Convert in.264 to out.ts again: ./testH264VideoToTransportStream # Demux it back to H.264 again: ffmpeg -i out.ts -vcodec copy demuxed02.h264 # Verify that the files are no longer the same: cmp in.264 demuxed02.h264 You will see that the demuxed02.h264 file is truncated in relation to the input file: $ ls -l in.264 demuxed0?.h264 -rw-r--r-- 1 test test 2680810 2012-07-18 13:59 in.264 -rw-r--r-- 1 test test 2680806 2012-07-18 13:59 demuxed01.h264 -rw-r--r-- 1 test test 2674518 2012-07-18 13:59 demuxed02.h264 I tested with version live.2012.07.14. Regards, John. -- -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 18 06:36:12 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jul 2012 06:36:12 -0700 Subject: [Live-devel] save the live video to local video In-Reply-To: <5FD979BDF2350C4796619C0AC619B38802F113DF3A@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> References: <5FD979BDF2350C4796619C0AC619B38802F113DF3A@FRMRSSXCHMBSA2X.dc-m.alcatel-lucent.com> Message-ID: <239597D4-7311-4CA0-A53F-B0EB2962E8D4@live555.com> > Howerver, for example, phone A start to live at time 00:00:00, phone B start to play the video at 00:10:00, that cause the test.ts file only save the ts packets from 00:10:00, the before 10 minites packets lost That's correct. The server doesn't start reading from the stream's input source until the first client requests the stream. > This is not I wanted. How can I save the live ts packets at the right begin time? If you want the server to start saving data immediately, then immediately after you start up the server, you could start up a client - perhaps one that's running on the same computer as the server - that reads from the stream. In fact, you could then make this client be the thing that saves the incoming data into a file. If you do that, then you won't need to add any duplication/file saving code to your server (which is a bit of an ugly hack anyway). > > Another problem: > And if I deleted the test.ts, then phone A start to live, phone B start to play, the ts packets will not saved, that is to say, no test.ts file! > Why? Because you're deleting the file while it's still open (and being written by the server). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 18 06:49:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jul 2012 06:49:15 -0700 Subject: [Live-devel] Add 454 (Session Not Found) handler to RTSPServer In-Reply-To: <1342609223.16925.17.camel@localhost.localdomain> References: <1342609223.16925.17.camel@localhost.localdomain> Message-ID: <18C6D042-F17D-419D-8CF0-1FFF581C69E9@live555.com> Yes, I'll be doing something like this when I update the server to handle multiple TCP connections per session. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.longney at logica.com Wed Jul 18 16:16:08 2012 From: ian.longney at logica.com (Longney, Ian) Date: Thu, 19 Jul 2012 09:16:08 +1000 Subject: [Live-devel] Issue with proxyserver and multiple clients Message-ID: >What OS is your host 128.129.224.101 running? >If you get the same result even when your clients are running on a different host from the proxy server, then please send >the complete debugging output from your proxy server (but not from the clients this time). I say "complete" debugging >output because last time you chopped off the output just at the point where the proxy server received the RTSP "DESCRIBE" >command from the second client. I ran the same test with the clients running on a different host to the proxy server and unfortunately the same thing happened. Both proxy server and clients are running on 64 bit Windows 7 laptops. The client is VLC version 2.0.1. Thank you Ian Longney ------------------------------------------------------------------------ --------------------- LIVE555 Proxy Server (LIVE555 Streaming Media library version 2012.07.06) Opening connection to 128.129.224.36, port 554... RTSP stream, proxying the stream "rtsp://128.129.224.36/live2.sdp" Play this stream using the URL "rtsp://128.129.224.101/proxyStream" (We use port 8000 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://128.129.224.36/live2.sdp RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.06) Accept: application/sdp Received 491 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Thu, 3 Jan 2000 17:35:50 GMT Content-Base: rtsp://128.129.224.36/live2.sdp/ Content-Type: application/sdp Content-Length: 327 v=0 o=RTSP 949599350 521 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=2 a=fmtp:98 packetization-mode=1; profile-level-id=4d001f; sprop-parameter-sets=Z00AH9oCgPZA,aO48gA== ProxyServerMediaSession["rtsp://128.129.224.36/live2.sdp/"] added new "ProxyServerMediaSubsession" for RTP/video/H264 track accept()ed connection from 128.129.224.86 Liveness indication from client at 128.129.224.86 Liveness indication from client at 128.129.224.86 RTSPClientSession[00253FE8]::handleRequestBytes() read 128 new bytes:OPTIONS rtsp://128.129.224.101/proxyStream RTSP/1.0 CSeq: 2 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "proxyStream", CSeq "2", Content-Length 0, with 0 bytes fo llowing the message. sending response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, Jul 18 2012 23:07:55 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Liveness indication from client at 128.129.224.86 RTSPClientSession[00253FE8]::handleRequestBytes() read 154 new bytes:DESCRIBE rtsp://128.129.224.101/proxyStream RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Accept: application/sdp parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "proxyStream", CSeq "3", Content-Length 0, with 0 bytes f ollowing the message. ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) RTCPInstance[0065E048]::RTCPInstance() schedule(1.697907->1342652876.950274) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() sending response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, Jul 18 2012 23:07:55 GMT Content-Base: rtsp://128.129.224.101/proxyStream/ Content-Type: application/sdp Content-Length: 524 v=0 o=- 1342652858199794 1 IN IP4 128.129.224.101 s=LIVE555 Streaming Media v2012.07.06 i=LIVE555 Streaming Media v2012.07.06 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.07.06 a=x-qt-text-inf:LIVE555 Streaming Media v2012.07.06 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=4D001F;sprop-parameter-sets=Z00AH9 oCgPZA,aO48gA== a=control:track1 Liveness indication from client at 128.129.224.86 RTSPClientSession[00253FE8]::handleRequestBytes() read 185 new bytes:SETUP rtsp://128.129.224.101/proxyStream/track1 RTSP/1.0 CSeq: 4 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Transport: RTP/AVP;unicast;client_port=60258-60259 parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "proxyStream", urlSuffix "track1", CSeq "4", Content-Length 0, with 0 byte s following the message. ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 2189106409) Sending request: SETUP rtsp://128.129.224.36/live2.sdp/trackID=2 RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.06) Transport: RTP/AVP;unicast;client_port=59104-59105 ProxyServerMediaSubsession["H264"]::createNewRTPSink() sending response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, Jul 18 2012 23:07:55 GMT Transport: RTP/AVP;unicast;destination=128.129.224.86;source=128.129.224.101;client _port=60258-60259;server_port=6970-6971 Session: 827B1CE9 Received 163 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Thu, 3 Jan 2000 17:36:7 GMT Session: 6664;timeout=80 Transport: RTP/AVP;unicast;client_port=59104-59105;server_port=5556-5557 ProxyRTSPClient["rtsp://128.129.224.36/live2.sdp/"]::continueAfterSETUP( ): head codec: H264; numSubsessions 1 queue: H264 Sending request: PLAY rtsp://128.129.224.36/live2.sdp/ RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.06) Session: 6664 Liveness indication from client at 128.129.224.86 RTSPClientSession[00253FE8]::handleRequestBytes() read 164 new bytes:PLAY rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 5 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Session: 827B1CE9 Range: npt=0.000- parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "proxyStream", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes follo wing the message. RTCPInstance[0065F6E8]::RTCPInstance() schedule(2.228234->1342652877.509800) sending response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, Jul 18 2012 23:07:55 GMT Range: npt=0.000- Session: 827B1CE9 RTP-Info: url=rtsp://128.129.224.101/proxyStream/track1;seq=51929;rtptime=41440149 93 Received 197 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Thu, 3 Jan 2000 17:36:7 GMT Session: 6664;timeout=80 RTP-Info: url=rtsp://128.129.224.36/live2.sdp/trackID=2;seq=0;rtptime=0 Range: npt=0- RTCP-Interval: 250 Liveness indication from client at 128.129.224.86 RTSPClientSession[00253FE8]::handleRequestBytes() read 154 new bytes:GET_PARAMETER rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 6 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Session: 827B1CE9 parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "proxyStream", urlSuffix "", CSeq "6", Content-Length 0, with 0 by tes following the message. sending response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, Jul 18 2012 23:07:55 GMT Session: 827B1CE9 [0065E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 00001a09 bc443b07 8c8b4000 00000000 00000001 00003532 81ca0008 00001a09 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x00001a09 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x00001a09 validated entire RTCP packet [0065E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 00001a09 bc443b08 2624dc00 0000d2f0 00000004 00007438 81ca0008 00001a09 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x00001a09 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x00001a09 validated entire RTCP packet schedule(0.421856->1342652877.377029) sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 0001004d 0000004e 3b082624 00015817 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(1.717735->1342652879.100383) schedule(0.542777->1342652878.052884) schedule(0.057629->1342652878.111844) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001cb34 0284075b 00000000 00000000 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR Adding new entry for SSRC 61ecfb4 in RTPTransmissionStatsDB RTCP RR data (received at 1342652878.100609): lossStats 0x00ffffff, lastPacketNumReceived 0x0001cb34, jitter 0x0284075b, lastSRTime 0x00000000, diffSR _RRTime 0x00000000 => round-trip delay: 0x0000 (== 0.000000 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet sending REPORT sending RTCP packet 80c80006 39d7383d d3b1c04e 1d17e77d f70472ec 0000005c 00019210 81ca0005 39d7383d 010d4155 2d4c3242 31333530 34334800 schedule(2.344634->1342652880.461866) schedule(0.866374->1342652879.967600) schedule(1.782033->1342652881.750292) schedule(1.290887->1342652881.754169) schedule(1.484037->1342652883.234899) schedule(2.427832->1342652884.183131) [0065E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 00001a09 bc443b0f 272b0000 000a7148 00000027 0004dcdf 81ca0008 00001a09 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x00001a09 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x00001a09 validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 0001011c 000000c6 3b0f272b 00001f23 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(2.821439->1342652886.060804) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001cc00 0069b578 c04e1d17 00057465 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652883.577334): lossStats 0x00ffffff, lastPacketNumReceived 0x0001cc00, jitter 0x0069b578, lastSRTime 0xc04e1d17, diffSR _RRTime 0x00057465 => round-trip delay: 0x0250 (== 0.009033 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet sending REPORT sending RTCP packet 80c80006 39d7383d d3b1c054 2f55475a f70cc959 00000142 0005876f 81ca0005 39d7383d 010d4155 2d4c3242 31333530 34334800 schedule(2.722525->1342652886.911197) sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 0001017d 000000b4 3b0f272b 0002f29d 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(5.408221->1342652891.473995) schedule(3.226223->1342652890.138648) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001cc91 001d13ea c0542f55 000374da 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652887.650802): lossStats 0x00ffffff, lastPacketNumReceived 0x0001cc91, jitter 0x001d13ea, lastSRTime 0xc0542f55, diffSR _RRTime 0x000374da => round-trip delay: 0x026c (== 0.009460 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet Sending request: OPTIONS rtsp://128.129.224.36/live2.sdp/ RTSP/1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.06) Received 114 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 5 Date: Thu, 3 Jan 2000 17:36:20 GMT Public: OPTIONS, DESCRIBE, PLAY, SETUP, TEARDOWN sending REPORT sending RTCP packet 80c80006 39d7383d d3b1c05a 247e5a79 f714f7d6 00000210 000924cc 81ca0005 39d7383d 010d4155 2d4c3242 31333530 34334800 schedule(4.070939->1342652894.217220) [0065E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 00001a09 bc443b16 5b22d000 00145596 0000004b 000975b3 81ca0008 00001a09 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x00001a09 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x00001a09 validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 00010253 000000bd 3b165b22 000149a9 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 reap: checking SSRC 0x1a09: 4 (threshold 0) schedule(4.514160->1342652896.001250) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001cd31 00070834 c05a247e 0001d681 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652891.989745): lossStats 0x00ffffff, lastPacketNumReceived 0x0001cd31, jitter 0x00070834, lastSRTime 0xc05a247e, diffSR _RRTime 0x0001d681 => round-trip delay: 0x0261 (== 0.009293 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet sending REPORT sending RTCP packet 80c80006 39d7383d d3b1c05e 37f96180 f71a90d6 000002b1 000bf490 81ca0005 39d7383d 010d4155 2d4c3242 31333530 34334800 reap: checking SSRC 0x61ecfb4: 4 (threshold 0) schedule(6.061100->1342652900.283565) accept()ed connection from 128.129.224.86 Liveness indication from client at 128.129.224.86 Liveness indication from client at 128.129.224.86 RTSPClientSession[0025DD98]::handleRequestBytes() read 128 new bytes:OPTIONS rtsp://128.129.224.101/proxyStream RTSP/1.0 CSeq: 2 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "proxyStream", CSeq "2", Content-Length 0, with 0 bytes fo llowing the message. sending response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, Jul 18 2012 23:08:15 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Liveness indication from client at 128.129.224.86 RTSPClientSession[0025DD98]::handleRequestBytes() read 154 new bytes:DESCRIBE rtsp://128.129.224.101/proxyStream RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Accept: application/sdp parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "proxyStream", CSeq "3", Content-Length 0, with 0 bytes f ollowing the message. sending response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, Jul 18 2012 23:08:15 GMT Content-Base: rtsp://128.129.224.101/proxyStream/ Content-Type: application/sdp Content-Length: 524 v=0 o=- 1342652858199794 1 IN IP4 128.129.224.101 s=LIVE555 Streaming Media v2012.07.06 i=LIVE555 Streaming Media v2012.07.06 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2012.07.06 a=x-qt-text-inf:LIVE555 Streaming Media v2012.07.06 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=4D001F;sprop-parameter-sets=Z00AH9 oCgPZA,aO48gA== a=control:track1 Liveness indication from client at 128.129.224.86 RTSPClientSession[0025DD98]::handleRequestBytes() read 185 new bytes:SETUP rtsp://128.129.224.101/proxyStream/track1 RTSP/1.0 CSeq: 4 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Transport: RTP/AVP;unicast;client_port=60260-60261 parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "proxyStream", urlSuffix "track1", CSeq "4", Content-Length 0, with 0 byte s following the message. sending response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, Jul 18 2012 23:08:15 GMT Transport: RTP/AVP;unicast;destination=128.129.224.86;source=128.129.224.101;client _port=60260-60261;server_port=6970-6971 Session: B1A8FDE6 Liveness indication from client at 128.129.224.86 RTSPClientSession[0025DD98]::handleRequestBytes() read 164 new bytes:PLAY rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 5 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Session: B1A8FDE6 Range: npt=0.000- parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "proxyStream", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes follo wing the message. sending response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, Jul 18 2012 23:08:15 GMT Range: npt=0.000- Session: B1A8FDE6 RTP-Info: url=rtsp://128.129.224.101/proxyStream/track1;seq=52651;rtptime=41458015 09 Liveness indication from client at 128.129.224.86 RTSPClientSession[0025DD98]::handleRequestBytes() read 154 new bytes:GET_PARAMETER rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 6 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Session: B1A8FDE6 parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "proxyStream", urlSuffix "", CSeq "6", Content-Length 0, with 0 by tes following the message. sending response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, Jul 18 2012 23:08:15 GMT Session: B1A8FDE6 sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 00010300 000000bf 3b165b22 0005ced9 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(5.212229->1342652901.218730) [0065E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 00001a09 bc443b1d 5c28f400 001df3ee 0000006e 000e0864 81ca0008 00001a09 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x00001a09 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x00001a09 validated entire RTCP packet [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001ce12 02851c81 c05e37f9 0003b521 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652897.934706): lossStats 0x00ffffff, lastPacketNumReceived 0x0001ce12, jitter 0x02851c81, lastSRTime 0xc05e37f9, diffSR _RRTime 0x0003b521 => round-trip delay: 0x022f (== 0.008530 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60261) 81c90007 bf628b06 39d7383d 00ffffff 0001ce15 00000106 00000000 00000000 81ca0005 bf628b06 010b4155 2d4c315a 47434354 31000000 RR Adding new entry for SSRC bf628b06 in RTPTransmissionStatsDB RTCP RR data (received at 1342652898.096097): lossStats 0x00ffffff, lastPacketNumReceived 0x0001ce15, jitter 0x00000106, lastSRTime 0x00000000, diffSR _RRTime 0x00000000 => round-trip delay: 0x0000 (== 0.000000 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0xbf628b06 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xbf628b06 validated entire RTCP packet sending REPORT sending RTCP packet 80c80006 39d7383d d3b1c064 48f5903a 4e7598e1 00000399 00101cdb 81ca0005 39d7383d 010d4155 2d4c3242 31333530 34334800 schedule(5.499054->1342652905.787278) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60261) 81c90007 bf628b06 39d7383d 00ffffff 0001ce82 000000cf c06448f5 0000842b 81ca0005 bf628b06 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652900.809957): lossStats 0x00ffffff, lastPacketNumReceived 0x0001ce82, jitter 0x000000cf, lastSRTime 0xc06448f5, diffSR _RRTime 0x0000842b => round-trip delay: 0x0239 (== 0.008682 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0xbf628b06 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xbf628b06 validated entire RTCP packet schedule(0.125067->1342652901.348574) schedule(0.432964->1342652901.786375) sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 000103ed 000000d3 3b1d5c28 00047d38 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(4.846455->1342652906.644066) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001ceff 005d106a c06448f5 0003815e 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652903.799091): lossStats 0x00ffffff, lastPacketNumReceived 0x0001ceff, jitter 0x005d106a, lastSRTime 0xc06448f5, diffSR _RRTime 0x0003815e => round-trip delay: 0x023e (== 0.008759 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet [0065E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 00001a09 bc443b24 9020c400 0027d83c 00000092 00132c4e 81ca0008 00001a09 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x00001a09 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x00001a09 validated entire RTCP packet [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60261) 81c90007 bf628b06 39d7383d 00ffffff 0001cf3d 000000ba c06448f5 0005313d 81ca0005 bf628b06 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652905.486323): lossStats 0x00ffffff, lastPacketNumReceived 0x0001cf3d, jitter 0x000000ba, lastSRTime 0xc06448f5, diffSR _RRTime 0x0005313d => round-trip delay: 0x024e (== 0.009003 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0xbf628b06 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xbf628b06 validated entire RTCP packet schedule(0.398082->1342652906.191422) sending REPORT sending RTCP packet 80c80006 39d7383d d3b1c06a 319a0f0a 4e7db62d 00000484 0014410a 81ca0005 39d7383d 010d4155 2d4c3242 31333530 34334800 schedule(5.383634->1342652911.581171) sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 000104ac 000000ad 3b249020 0002454f 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(5.014331->1342652911.672540) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001cfba 0013c691 c06a319a 00027cf2 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652908.691519): lossStats 0x00ffffff, lastPacketNumReceived 0x0001cfba, jitter 0x0013c691, lastSRTime 0xc06a319a, diffSR _RRTime 0x00027cf2 => round-trip delay: 0x027b (== 0.009689 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60261) 81c90007 bf628b06 39d7383d 00ffffff 0001cfe8 000000a3 c06a319a 0003e4a9 81ca0005 bf628b06 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652910.096400): lossStats 0x00ffffff, lastPacketNumReceived 0x0001cfe8, jitter 0x000000a3, lastSRTime 0xc06a319a, diffSR _RRTime 0x0003e4a9 => round-trip delay: 0x026b (== 0.009445 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0xbf628b06 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0xbf628b06 validated entire RTCP packet [0065E048]saw incoming RTCP packet (from address 128.129.224.36, port 5557) 80c80006 00001a09 bc443b2b 9126e800 00317694 000000b5 0017f833 81ca0008 00001a09 01175374 7265616d 696e6753 65727665 7240302e 302e302e 30000000 SR RR validated RTCP subpacket (type 2): 0, 200, 0, 0x00001a09 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 28, 0x00001a09 validated entire RTCP packet sending REPORT sending RTCP packet 80c80006 39d7383d d3b1c06f 9532c626 4e851cc4 00000548 0017bd7f 81ca0005 39d7383d 010d4155 2d4c3242 31333530 34334800 schedule(4.032602->1342652915.618892) schedule(0.192397->1342652911.865710) schedule(0.648559->1342652912.514921) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001d02e 00069a83 c06f9532 00009398 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652912.168540): lossStats 0x00ffffff, lastPacketNumReceived 0x0001d02e, jitter 0x00069a83, lastSRTime 0xc06f9532, diffSR _RRTime 0x00009398 => round-trip delay: 0x025b (== 0.009201 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 00010586 0000011c 3b2b9126 00010db5 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(5.882401->1342652918.403616) sending REPORT sending RTCP packet 80c80006 39d7383d d3b1c073 9eb26bf8 4e8aa80f 000005d3 001a2958 81ca0005 39d7383d 010d4155 2d4c3242 31333530 34334800 schedule(3.143699->1342652918.766882) Liveness indication from client at 128.129.224.86 RTSPClientSession[0025DD98]::handleRequestBytes() read 149 new bytes:TEARDOWN rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 7 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Session: B1A8FDE6 parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix "proxyStream", urlSuffix "", CSeq "7", Content-Length 0, with 0 bytes f ollowing the message. sending response: RTSP/1.0 200 OK CSeq: 7 Date: Wed, Jul 18 2012 23:08:35 GMT [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60261) 81c90007 bf628b06 39d7383d 00ffffff 0001d0ac 000000b7 c0739eb2 00002563 81cb0001 bf628b06 RR RTCP RR data (received at 1342652915.774642): lossStats 0x00ffffff, lastPacketNumReceived 0x0001d0ac, jitter 0x000000b7, lastSRTime 0xc0739eb2, diffSR _RRTime 0x00002563 => round-trip delay: 0x023a (== 0.008698 seconds) validated RTCP subpacket (type 2): 1, 201, 0, 0xbf628b06 BYE validated RTCP subpacket (type 3): 1, 203, 0, 0xbf628b06 validated entire RTCP packet schedule(1.992179->1342652917.770784) [0065F6E8]saw incoming RTCP packet (from address 128.129.224.86, port 60259) 81c90007 061ecfb4 39d7383d 00ffffff 0001d0df 00015161 c0739eb2 000186ea 81ca0005 061ecfb4 010b4155 2d4c315a 47434354 31000000 RR RTCP RR data (received at 1342652917.155666): lossStats 0x00ffffff, lastPacketNumReceived 0x0001d0df, jitter 0x00015161, lastSRTime 0xc0739eb2, diffSR _RRTime 0x000186ea => round-trip delay: 0x023e (== 0.008759 seconds) Liveness indication from client at 128.129.224.86 validated RTCP subpacket (type 2): 1, 201, 0, 0x061ecfb4 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x061ecfb4 validated entire RTCP packet schedule(3.582291->1342652921.357765) Liveness indication from client at 128.129.224.86 RTSPClientSession[00253FE8]::handleRequestBytes() read 149 new bytes:TEARDOWN rtsp://128.129.224.101/proxyStream/ RTSP/1.0 CSeq: 7 User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23) Session: 827B1CE9 parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix "proxyStream", urlSuffix "", CSeq "7", Content-Length 0, with 0 bytes f ollowing the message. sending response: RTSP/1.0 200 OK CSeq: 7 Date: Wed, Jul 18 2012 23:08:38 GMT RTCPInstance[0065F6E8]::~RTCPInstance() sending BYE sending RTCP packet 80c80006 39d7383d d3b1c076 5fb6cbda 4e8e7040 0000062f 001bcdc4 81cb0001 39d7383d ProxyServerMediaSubsession["H264"]::closeStreamSource() Sending request: PAUSE rtsp://128.129.224.36/live2.sdp/ RTSP/1.0 CSeq: 6 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.06) Session: 6664 Received 43 new bytes of response data. Received a complete PAUSE response: RTSP/1.0 200 OK CSeq: 6 Session: 6664 sending REPORT sending RTCP packet 81c90007 abb5542e 00001a09 00ffffff 0001065d 000000e2 3b2b9126 0006f160 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 reap: checking SSRC 0x1a09: 8 (threshold 5) schedule(3.602973->1342652922.013973) sending REPORT sending RTCP packet 80c90001 abb5542e 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(4.917518->1342652926.935998) schedule(1.146394->1342652928.090759) sending REPORT sending RTCP packet 80c90001 abb5542e 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(4.796952->1342652932.924055) sending REPORT sending RTCP packet 80c90001 abb5542e 81ca0005 abb5542e 010d4155 2d4c3242 31333530 34334800 schedule(4.612392->1342652937.539981) Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 18 17:00:19 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jul 2012 17:00:19 -0700 Subject: [Live-devel] Issue converting H.264 with EOS NALU to MPEG-TS In-Reply-To: References: Message-ID: <4D40C697-4FE3-4D5A-9D44-9782FD5C57BC@live555.com> Thanks for the report. I've just installed a new version - 2012.07.18 - of the "LIVE555 Streaming Media" code that should fix this problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 18 17:07:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jul 2012 17:07:56 -0700 Subject: [Live-devel] Issue with proxyserver and multiple clients In-Reply-To: References: Message-ID: Thanks for the debugging log. Unfortunately I still can't figure out why the arrival of a second client could be causing the proxy to stop delivery to the first one. The only thing I can think of right now is that it might be some (unknown) issue that's specific to Windows, and that perhaps if you were to run the proxy on some other OS, then it might work OK. (Because this is not a problem that I can reproduce right now.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 18 17:28:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jul 2012 17:28:51 -0700 Subject: [Live-devel] Issue with proxyserver and multiple clients In-Reply-To: References: Message-ID: <73EDF4BD-D57C-4FB1-90F4-9F451AC58BFC@live555.com> Just now I tried running the proxy server on a Windows computer, and couldn't reproduce the problem. So unfortunately I'm completely out of ideas... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abmadaan at yahoo.com Wed Jul 18 15:01:40 2012 From: abmadaan at yahoo.com (Abhishek Madaan) Date: Wed, 18 Jul 2012 15:01:40 -0700 (PDT) Subject: [Live-devel] Video Delay in Live Video Streaming Message-ID: <1342648900.17759.YahooMailNeo@web114516.mail.gq1.yahoo.com> Hi, ????? I?am showing a?H.264 stream using live555 library. The?H.264 data is coming over RTSP. Once I?receive the data, I decode the H.264 data using FFMPEG library. I am able to get?video out of?the camera and able to?view it in a MFC GUI application. The only?problem is that there is a?delay (lag)?in video for?about 30-60 seconds. The longer the stream runs, more the video?lags.?I tried to look in to the code but couldn't find why this lag is happening. I also have seen online where other people are facing the same issue. But I couldn't find no solution to this problem. If you can help me regarding this that would be really appreciated. ? Regards, Abhishek Madaan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 18 18:44:07 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jul 2012 18:44:07 -0700 Subject: [Live-devel] Video Delay in Live Video Streaming In-Reply-To: <1342648900.17759.YahooMailNeo@web114516.mail.gq1.yahoo.com> References: <1342648900.17759.YahooMailNeo@web114516.mail.gq1.yahoo.com> Message-ID: <10149E33-3D12-4A90-82B7-382861E84D81@live555.com> First, you should instead consider using the existing (open source) VLC media player , which also uses our libraries for its RTSP client implementation. The increasing delay that you are seeing is unlikely to be due to a problem with our libraries. One possible cause is that your computer doesn't have enough CPU power to handle the video decoding and rendering (as well as the RTSP/RTP reception, which has relatively little overhead). One way to test this hypothesis is to try running VLC instead. Another possibility is that you are not using the 'presentation times' for each received video frame (in this case, H.264 'NAL units') correctly. Each frame's "presentation time" tells you the relative time at which each frame should be displayed (after decoding). But in any case, because you are a casual hobbyist, I suggest just using VLC. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abmadaan at yahoo.com Wed Jul 18 20:37:45 2012 From: abmadaan at yahoo.com (Abhishek Madaan) Date: Wed, 18 Jul 2012 20:37:45 -0700 (PDT) Subject: [Live-devel] Video Delay in Live Video Streaming In-Reply-To: <10149E33-3D12-4A90-82B7-382861E84D81@live555.com> References: <1342648900.17759.YahooMailNeo@web114516.mail.gq1.yahoo.com> <10149E33-3D12-4A90-82B7-382861E84D81@live555.com> Message-ID: <1342669065.81752.YahooMailNeo@web114516.mail.gq1.yahoo.com> Hi Ross Finlayson,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Thanks for the reply. I didn't say that delay is happening due to a problem with your libraries. I don't have experience with your library and I am still learning. I can play the camera in VLC player and it runs fine. Although i have to make the caching 200ms in VLC player as well for it to have no delay. I am running windows and not easy to import VLC player code in Visual Studio. Also I don't want to copy VLC code either. Could you please explain on the following part which you mentioned in the last email: Another possibility is that you are not using the 'presentation times' for each received video frame (in this case, H.264 'NAL units') correctly. ?Each frame's "presentation time" tells you the relative time at which each frame should be displayed (after decoding). I am adding 0001 with every frame. What you have done in the H264FileSink, basically I am doing in dummysink class of testRTSp. Thanks Regards, Abhishek Madaan? ________________________________ From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Wednesday, July 18, 2012 8:44 PM Subject: Re: [Live-devel] Video Delay in Live Video Streaming First, you should instead consider using the existing (open source) VLC media player , which also uses our libraries for its RTSP client implementation. The increasing delay that you are seeing is unlikely to be due to a problem with our libraries. One possible cause is that your computer doesn't have enough CPU power to handle the video decoding and rendering (as well as the RTSP/RTP reception, which has relatively little overhead). ?One way to test this hypothesis is to try running VLC instead. Another possibility is that you are not using the 'presentation times' for each received video frame (in this case, H.264 'NAL units') correctly. ?Each frame's "presentation time" tells you the relative time at which each frame should be displayed (after decoding). But in any case, because you are a casual hobbyist, I suggest just using VLC. 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 bstump at codemass.com Thu Jul 19 14:37:18 2012 From: bstump at codemass.com (Barry Stump) Date: Thu, 19 Jul 2012 14:37:18 -0700 Subject: [Live-devel] Detecting socket close when receiving streams via TCP In-Reply-To: <1F5C5835-A07C-4253-A860-67917EFD990D@live555.com> References: <1F5C5835-A07C-4253-A860-67917EFD990D@live555.com> Message-ID: My apologies for taking so long to reply, OSCON has been taking up all my time this week. > I *might* be able to modify the "readSocket()" function to better handle > this case, but I don't want to risk inadvertently messing up higher-level > code that uses this function by mishandling cases when "recvfrom()" might > return zero in a *non*-error situation. > > In the situation that you are concerned about - recvfrom() returning "zero > if the connection is TCP and the peer has closed its half side of the > connection" - what is the value of "errno" in this case? (If it's > something non-zero, then I should be able to update "readSocket()" to add a > test for this.) > By design, errno is only set when the return value is negative. Socket close (EOF) is not considered an error, and is indicated instead by a zero return value. This is the only use of a zero return value for TCP sockets on POSIX. Here's an example of Apache HTTPD relying on zero return value to detect socket close/EOF (taken from http://svn.apache.org/viewvc/apr/apr/trunk/network_io/unix/sendrecv.c?view=markup) apr_status_t apr_socket_recvfrom(apr_sockaddr_t *from, apr_socket_t *sock, apr_int32_t flags, char *buf, apr_size_t *len) { // ...snip... do { rv = recvfrom(sock->socketdes, buf, (*len), flags, (struct sockaddr*)&from->sa, &from->salen); } while (rv == -1 && errno == EINTR); // ...snip... if (rv == 0 && sock->type == SOCK_STREAM) { return APR_EOF; } return APR_SUCCESS; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 19 16:14:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Jul 2012 16:14:02 -0700 Subject: [Live-devel] Detecting socket close when receiving streams via TCP In-Reply-To: References: <1F5C5835-A07C-4253-A860-67917EFD990D@live555.com> Message-ID: <99F13064-04A6-4E3A-8458-64C801CE432B@live555.com> OK, I think I was able to handle this better by making a small change to the "RTPInterface" code, in the places where it calls "readSocket()" on TCP sockets. Please try the attached version of "liveMedia/RTPInterface.cpp", and let me know if this works better for you in this situation (and doesn't mess up in other situations). If this new version of "RTPInterface.cpp" turns out work OK, I'll include it in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTPInterface.cpp Type: application/octet-stream Size: 16818 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 19 16:15:25 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Jul 2012 16:15:25 -0700 Subject: [Live-devel] Detecting socket close when receiving streams via TCP In-Reply-To: References: Message-ID: But in any case, I still think you should consider a higher-level mechanism for detecting server death, as outlined in Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Fri Jul 20 10:02:04 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Fri, 20 Jul 2012 22:32:04 +0530 Subject: [Live-devel] MJPEG Streaming Support in Live555 Message-ID: Hi Ross, We are developing live555 based application for streaming MJPEG frames from a USB camera over Wifi. MJPEG frames from camera we have captured and analyzed. Each frame is one complete JPEG image with headers (ie SOI = FF D8, EOI = FF D9). On the receiver side we are receiving the frames with changed header formatting & following errors are continuously displayed by an Live555 based iOS application (testRTSPClient taken as a reference). ImageIO: JPEGCorrupt JPEG data: premature end of data segment ImageIO: JPEGCorrupt JPEG data: premature end of data segment We have found that JPEGVideoRTPSource.cpp is creating JPEG headers and overwriting the incoming data headers. How JPEGVideoRTP* interface need to be used in our scenario, where we need not to change or add any header information & send the payload as it as with inbuilt JPEG header. Please provide your feedbacks. Thanks & Regards, Ashfaque -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jul 21 07:29:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Jul 2012 07:29:20 -0700 Subject: [Live-devel] MJPEG Streaming Support in Live555 In-Reply-To: References: Message-ID: <406CD336-6338-488B-A0B5-E327E8254FDA@live555.com> > We are developing live555 based application for streaming MJPEG frames from a USB camera over Wifi. Note this FAQ entry, which you should have already read: http://www.live555.com/liveMedia/faq.html#jpeg-streaming And note the two links in that FAQ entry: http://lists.live555.com/pipermail/live-devel/2005-January/001908.html http://lists.live555.com/pipermail/live-devel/2003-November/000037.html which tell you that: 1/ Streaming JPEG over RTP is a terrible idea, and 2/ The frames that are delivered by your "JPEGVideoSource" subclass to the "JPEGVideoRTPSink" DO NOT include a JPEG header. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abmadaan at yahoo.com Sat Jul 21 06:38:14 2012 From: abmadaan at yahoo.com (Abhishek Madaan) Date: Sat, 21 Jul 2012 06:38:14 -0700 (PDT) Subject: [Live-devel] Video Delay in Live Video Streaming In-Reply-To: <10149E33-3D12-4A90-82B7-382861E84D81@live555.com> References: <1342648900.17759.YahooMailNeo@web114516.mail.gq1.yahoo.com> <10149E33-3D12-4A90-82B7-382861E84D81@live555.com> Message-ID: <1342877894.78004.YahooMailNeo@web114516.mail.gq1.yahoo.com> Hi Ross, ????????????? I able to solve the delay issue. It is not related to your library. I was not allocating the buffer correctly. It is all working now. I appreciate all the help you provided me. ? Regards, Abhishek Madaan ________________________________ From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Wednesday, July 18, 2012 8:44 PM Subject: Re: [Live-devel] Video Delay in Live Video Streaming First, you should instead consider using the existing (open source) VLC media player , which also uses our libraries for its RTSP client implementation. The increasing delay that you are seeing is unlikely to be due to a problem with our libraries. One possible cause is that your computer doesn't have enough CPU power to handle the video decoding and rendering (as well as the RTSP/RTP reception, which has relatively little overhead). ?One way to test this hypothesis is to try running VLC instead. Another possibility is that you are not using the 'presentation times' for each received video frame (in this case, H.264 'NAL units') correctly. ?Each frame's "presentation time" tells you the relative time at which each frame should be displayed (after decoding). But in any case, because you are a casual hobbyist, I suggest just using VLC. 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 devildoggodlived at cfl.rr.com Sat Jul 21 14:11:28 2012 From: devildoggodlived at cfl.rr.com (MDH) Date: Sat, 21 Jul 2012 17:11:28 -0400 Subject: [Live-devel] Used VLC, already broken up video into segments - how can I now use Live555 Message-ID: <20120721171128.520818cd@mheath-TECRA-M11> Ross, I believe you responded to an inquiry I made to the Darwin mailing list a while back... But let me restate my problem.... Scenerio --> I have a few hundred++ mp4s that work fine using Darwin as a server and Quicktime as a client and whatever else will work as a client! 1) I Tested Live555 Media server (and still have it running on my machine!) -- and I tested successfully your "bipbop-gear1-all" test files successfully using iPhone iOS 4x... 2) ==> Then I found this using VLC which I used to convert all my few hundred++ mp4s to the "broken up video segments" -- see this link --> http://mdhradio.dnsdojo.net/heathvision/MDHRadio/example.txt ------------------ (Note: the reason I used VLC was because the Apple N---'s decided that since my apple.developer account was associated to a Mac mini G4, that they could not give me the new HTTP streaming tools ;( 3) Then, viola, all I had to do was use my standard Apache http server, and iPhone iOS 4 worked perfectly -- All I had to do was point to the index file with an iPhone using Safari and the broken up video segments played perfectly just like apple stated..!! ==> I mean, I had an easy way to bypass Live555 and then just continue to use Darwin otherwise! (hint: yet Live555 is still running with nothing to do currently!) 4) Then, we upgrade to iPhone iOS 5 ----> and Safari is BROKEN ;( --> This was MOST ridiculous to me ;( ;) --> There is some kind of "multi-cast" whatever..., (from my research.....) 5) This is a major debacle for me, since it took me weeks to run the VLC script to convert everything... 6) The issue -- I have all this work done to convert everything to "broken up video into segments", and I need a way to play these via Live555 without having to do this all over again.... 7) when looking at your "bipbop-gear1-all" it seems to me these were created using the Apple http streaming tools... so the index file you refer to is in binary... Please help... Otherwise, I am stuck with Darwin and no iPhone streaming methods... Thanks, Michael -- http://mdhradio.dnsdojo.net/heathvision/HeathVision/Start.html From finlayson at live555.com Sat Jul 21 15:41:27 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Jul 2012 15:41:27 -0700 Subject: [Live-devel] Used VLC, already broken up video into segments - how can I now use Live555 In-Reply-To: <20120721171128.520818cd@mheath-TECRA-M11> References: <20120721171128.520818cd@mheath-TECRA-M11> Message-ID: <05F047C5-4B90-4E12-AD4E-AE5B8ABCC812@live555.com> I couldn't really understand all of this rambling message (but since your email address announces to the world that you are just a casual hobbyist rather than a serious professional, I really don't care). But from what I can tell, you are asking how to use the "LIVE555 Media Server" to stream a file (or set of files) to an iPhone/iPad, using Apple's "HTTP Live Streaming" protocol. This is described quite specifically here: http://www.live555.com/mediaServer/#http-live-streaming Note, in particular, that a media file streamed by the server *must* be a single *Transport Stream* file (i.e., not split into multiple files), and must have an index file (which our documentation also tells you how to create). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at cyberdev.com Sun Jul 22 16:40:20 2012 From: frank at cyberdev.com (Frank Vernon) Date: Sun, 22 Jul 2012 17:40:20 -0600 Subject: [Live-devel] RTSP streaming AAC on iOS Message-ID: <9B28B3C0-B59E-4367-83D9-C77E5065BD36@cyberdev.com> Hi- I'm looking for some advice on streaming AAC via RTSP on iOS from a webcam. Hopefully someone has done this before and can point out my mistake. I have been successfully using the Live555 libraries with uLaw encoded audio for some time and am now trying to do the same for AAC on a newer camera. I am attempting to do this via the iOS Audio File Stream APIs (AudioFileStreamOpen/AudioFileStreamParseBytes). First, can anyone tell me if this is the correct way to do this? I assume once I receive the AAC frames in my custom RTSP stream sink class that the data still needs to be parsed to AAC packets and that the audio file stream API is the way to do that. Unfortunately, AudioFileStreamParseBytes is not correctly finding AAC packets and/or properties in the data so I never get actual AAC packets to play. This is fairly frustrating as AudioFileStreamParseBytes does not generate any errors to let me know what I might be doing wrong. I am assuming that the data from the Live555 utility routine parseGeneralConfigStr is the so-called Magic Cookie data that AAC decoders need. As this is apparently stripped out of the stream early by the Live555 libraries and iOS Audio File Stream APIs expect to find it in the stream how do I hand this off to iOS Audio File Stream APIs? Are there any byte order issues I need to address for the ARM platform when handing off the data? Thanks- Frank Vernon From bruno at maxcom.hr Mon Jul 23 04:42:32 2012 From: bruno at maxcom.hr (Bruno Babic) Date: Mon, 23 Jul 2012 13:42:32 +0200 Subject: [Live-devel] HTTP-based control of RTSP clients In-Reply-To: <9B28B3C0-B59E-4367-83D9-C77E5065BD36@cyberdev.com> References: <9B28B3C0-B59E-4367-83D9-C77E5065BD36@cyberdev.com> Message-ID: <500D38A8.1070508@maxcom.hr> Hi, I'm tryimg to make simple HTTP-based control of RTSP clients, i.e. I want to be able to start/stop one or more RTSP clients by sending appropriate HTTP request. I would like to implement this by using live555 code as much as possible, especially since there's already test RTSP server implementation available (which is quite similar to HTTP)... but, I have tight deadline and I can not spend too much time trying to understand how and why is something done like it is done. Can anybody (Ross maybe?) give me few pointers on how to implement simple HTTP server properly? It does not have to be actual code, it can be just few hints on how to have my server listen for connections and make TaskScheduler forward requests to my handler? P.S. if such piece of code is considered as useful, I'd gladly contribute source code to be added to test programs. -- Bruno Babi? maxcom d.o.o. Zagreba?ka 94 HR-42000 Vara?din Tel: +385 42 204 137 Fax: +385 42 204 138 GSM: +385 91 62 92 666 From shivkumarb at interfaceinfosoft.com Mon Jul 23 02:57:31 2012 From: shivkumarb at interfaceinfosoft.com (Shivkumar Bhasmare) Date: Mon, 23 Jul 2012 15:27:31 +0530 Subject: [Live-devel] How to Handle multiple streamers using "test on demand rtsp server" Message-ID: Hello Sir i made an application in which i receive the streaming data from different streamers on my server where i have placed your "test on demand rtsp server" code. At my server side i am creating an globally rtsp server and every time whenever the new streamer start streaming it send a message that new streamer has started and then on server side i create thread in which i have placed the code to receive the MPEG -2 Transport stream, Sir the problem is for one streamer it works well but when i run thread for the second streamer my code breaks at the following line:- "env->taskScheduler().doEventLoop();" Can u just tell me how to receive concurrent multiple streams using your "test on demand rtsp server" code. Thanks Shiv Interface infosoft Pvt Ltd. India -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter_bridge at hotmail.com Mon Jul 23 06:52:53 2012 From: peter_bridge at hotmail.com (Peter Bridge) Date: Mon, 23 Jul 2012 16:52:53 +0300 Subject: [Live-devel] using live555 with iOS Message-ID: I'm trying to decode some H.264 and AAC. It seems like live555 would be ideal for this task, but I'm getting mixed advice about LGPL under iOS for paid AppStore Apps. I get the impression many developers are just including live555 regardless in their paid apps, which puts me at a huge disadvantage. Is there something about LGPL that I'm missing that does allow inclusion of live555 in such a project? I don't want to distribute my source, and distributing my .o files seems like cheating the licensing, since I can't imagine anyone being able to reconstruct the app in any meaningful way without jail-breaking a device. I really appreciate the efforts involved in open source having contributed myself to some projects. So I don't want to be another developer just embedding it regardless. TIA for any advice. Peter. From finlayson at live555.com Mon Jul 23 07:44:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Jul 2012 07:44:20 -0700 Subject: [Live-devel] How to Handle multiple streamers using "test on demand rtsp server" In-Reply-To: References: Message-ID: > Can u just tell me how to receive concurrent multiple streams using your "test on demand rtsp server" code. As stated clearly in the FAQ (that you were asked to read before posting to this mailing list :-), LIVE555-based applications are single-threaded, using an event loop, rather than multiple threads, for concurrency. Having a RTSP server support multiple streams is easy - simply call "addServerMediaSession" multiple times, once for each such stream - before you call "doEventLoop()" to start the server running. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 23 07:58:32 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Jul 2012 07:58:32 -0700 Subject: [Live-devel] using live555 with iOS In-Reply-To: References: Message-ID: > I don't want to distribute my source And you don't have to. Because the "LIVE555 Streaming Media" code is LGPL, and not GPL, you don't need to distribute your application's source code, only the LIVE555 code. (If, as is preferred, you do not modify the LIVE555 code at all, you can do this simply by noting the URL ) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboom at channelislands.com Mon Jul 23 12:30:22 2012 From: mboom at channelislands.com (Michael L. Boom) Date: Mon, 23 Jul 2012 12:30:22 -0700 Subject: [Live-devel] Range Header In-Reply-To: References: <8CE79E3CB2664753A3AA216BB47D82A7@Work> Message-ID: Thanks for the help. Also, when I play with a range of "now-60" and a scale of greater than 1 (fast forward) it will play way past 60 seconds although it does stop eventually. Any idea why? Thanks. From: Ross Finlayson Sent: Friday, July 13, 2012 6:39 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Range Header Thanks for the note. I have now installed a new version (2012.07.14) of the "LIVE555 Streaming Media" code that updates the RTSP server implementation to properly handle "Range:" headers like "Range: npt=-60". (The prebuilt binary versions of the "LIVE555 Media Server" have not yet been updated; for the next few days, if you want to get this change, you will need to download and build the server from source code.) And yes, the keyword "now" is supposed to be reserved for live events, but in the spirit of "be liberal in what you accept", we also handle it if is used for a prerecorded stream. (Clients, however, should not be using it for such streams.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 23 12:43:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Jul 2012 12:43:03 -0700 Subject: [Live-devel] Range Header In-Reply-To: References: <8CE79E3CB2664753A3AA216BB47D82A7@Work> Message-ID: <51CECC72-536F-4271-B8D1-52585B908E67@live555.com> The server code interprets "now-60" (which, as you noted, the client shouldn't really be sending anyway, because it's not a live event) the same as "0-60". If you want to play starting from a specific time, then you'll need to include that time as the start time in the client's "Range:" header. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboom at channelislands.com Mon Jul 23 13:05:19 2012 From: mboom at channelislands.com (Michael L. Boom) Date: Mon, 23 Jul 2012 13:05:19 -0700 Subject: [Live-devel] Range Header In-Reply-To: <51CECC72-536F-4271-B8D1-52585B908E67@live555.com> References: <8CE79E3CB2664753A3AA216BB47D82A7@Work> <51CECC72-536F-4271-B8D1-52585B908E67@live555.com> Message-ID: <527BA5F8C28A4D9982F00935D661DF2B@Work> Thanks. I don't think I made myself clear though. When I fast forward with a range it doesn't stop at the requested end time (but it does stop a little while after it). When I fast forward with a range it seems to get confused and play to much. From: Ross Finlayson Sent: Monday, July 23, 2012 12:43 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Range Header The server code interprets "now-60" (which, as you noted, the client shouldn't really be sending anyway, because it's not a live event) the same as "0-60". If you want to play starting from a specific time, then you'll need to include that time as the start time in the client's "Range:" header. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 23 13:17:07 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Jul 2012 13:17:07 -0700 Subject: [Live-devel] Range Header In-Reply-To: <527BA5F8C28A4D9982F00935D661DF2B@Work> References: <8CE79E3CB2664753A3AA216BB47D82A7@Work> <51CECC72-536F-4271-B8D1-52585B908E67@live555.com> <527BA5F8C28A4D9982F00935D661DF2B@Work> Message-ID: <6E9B28C2-B5CF-4637-B708-ED6B496F9C30@live555.com> > Thanks. I don't think I made myself clear though. When I fast forward with a range it doesn't stop at the requested end time (but it does stop a little while after it). When I fast forward with a range it seems to get confused and play to much. I don't follow this (perhaps one of the "with"s should have been a "without"?). But in any case, the best way to test issues like this is to use the "openRTSP" RTSP client tool. Note the 'trick play' options: "-s ", "-z ", and "-d " See: http://www.live555.com/openRTSP/ I presume that your server is using indexed Transport Stream files for 'trick play'. If you can reproduce - using "openRTSP" - a specific problem with one of your files, then please tell us about it (by putting it on a publicly accessible web server), and let us know the specific "openRTSP" commands that cause a problem. Then we can test this for ourselves. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboom at channelislands.com Mon Jul 23 15:54:53 2012 From: mboom at channelislands.com (Michael L. Boom) Date: Mon, 23 Jul 2012 15:54:53 -0700 Subject: [Live-devel] Range Header In-Reply-To: <6E9B28C2-B5CF-4637-B708-ED6B496F9C30@live555.com> References: <8CE79E3CB2664753A3AA216BB47D82A7@Work><51CECC72-536F-4271-B8D1-52585B908E67@live555.com><527BA5F8C28A4D9982F00935D661DF2B@Work> <6E9B28C2-B5CF-4637-B708-ED6B496F9C30@live555.com> Message-ID: <34E799C37151466AA8D7E20E680FC8D7@Work> Ok. I tried your test program. I tried with scale of 1 and 2. If the client sends "Range: npt=30.000-60.000" the server plays starting at 30 seconds into the clip (clip timing information - not wall time) and plays for 30 seconds wall time (which for scale 2 will be 60 seconds of clip time). Shouldn't the server only stream 30 seconds according to the PTS/DTS and ignore the wall clock time for range not equal to 1? Thanks. From: Ross Finlayson Sent: Monday, July 23, 2012 1:17 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Range Header Thanks. I don't think I made myself clear though. When I fast forward with a range it doesn't stop at the requested end time (but it does stop a little while after it). When I fast forward with a range it seems to get confused and play to much. I don't follow this (perhaps one of the "with"s should have been a "without"?). But in any case, the best way to test issues like this is to use the "openRTSP" RTSP client tool. Note the 'trick play' options: "-s ", "-z ", and "-d " See: http://www.live555.com/openRTSP/ I presume that your server is using indexed Transport Stream files for 'trick play'. If you can reproduce - using "openRTSP" - a specific problem with one of your files, then please tell us about it (by putting it on a publicly accessible web server), and let us know the specific "openRTSP" commands that cause a problem. Then we can test this for ourselves. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 23 18:20:07 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Jul 2012 18:20:07 -0700 Subject: [Live-devel] Range Header In-Reply-To: <34E799C37151466AA8D7E20E680FC8D7@Work> References: <8CE79E3CB2664753A3AA216BB47D82A7@Work><51CECC72-536F-4271-B8D1-52585B908E67@live555.com><527BA5F8C28A4D9982F00935D661DF2B@Work> <6E9B28C2-B5CF-4637-B708-ED6B496F9C30@live555.com> <34E799C37151466AA8D7E20E680FC8D7@Work> Message-ID: > Ok. I tried your test program. I tried with scale of 1 and 2. If the client sends "Range: npt=30.000-60.000" the server plays starting at 30 seconds into the clip (clip timing information - not wall time) and plays for 30 seconds wall time (which for scale 2 will be 60 seconds of clip time). > > Shouldn't the server only stream 30 seconds according to the PTS/DTS and ignore the wall clock time for range not equal to 1? Yes. This is a bug that I'll need to fix. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivkumarb at interfaceinfosoft.com Tue Jul 24 00:24:28 2012 From: shivkumarb at interfaceinfosoft.com (Shivkumar Bhasmare) Date: Tue, 24 Jul 2012 12:54:28 +0530 Subject: [Live-devel] How to Handle multiple streamers using "test on demand rtsp server" In-Reply-To: References: Message-ID: Hello Sir First of all sorry for miss writing the question. My question is:-as i stated i make the rtsp server globally and put into thread the MPEG-2 Transport stream code. For the first streamer it works well and for the second streamer it breaks at "do event loop" .i.e. suppose the server is receiving stream from the first streamer and after 5 minutes the second streamer i also available and server also want to receive the stream from the second streamer,when the second streamer is available i call the thread code having MPEG-2 Transport stream code then my ode breaks at " do event loop". That's all my problem is now please tell me how to handle this. Thanks Shiv Interface infosoft Pvt Ltd. India -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.lc at vaelsys.com Tue Jul 24 04:08:33 2012 From: jesus.lc at vaelsys.com (=?ISO-8859-1?Q?Jes=FAs_Legan=E9s?=) Date: Tue, 24 Jul 2012 13:08:33 +0200 Subject: [Live-devel] Unitialized value Message-ID: I'm having some problems and debugging with Valgrin, it's raising a "Conditional jump or move depends on uninitialised value(s)" error. Looking at the code i have got that ProxyServerMediaSession::fClientMediaSession is not being initialized, waiting until the ProxyServerMediaSession::afterDescribe is being called, so for example at destructor would be able to cause problems. Just setting it to NULL on the constructor would be enought. -- Jes?s Legan?s Combarro Software developer at Vaelsys From finlayson at live555.com Tue Jul 24 06:18:31 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Jul 2012 06:18:31 -0700 Subject: [Live-devel] Unitialized value In-Reply-To: References: Message-ID: <43DA4E2A-25FD-4F2C-8AAA-3B4834B01C4B@live555.com> Thanks. This will be fixed in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.santanche at tiscali.it Tue Jul 24 07:18:14 2012 From: d.santanche at tiscali.it (d.santanche at tiscali.it) Date: Tue, 24 Jul 2012 16:18:14 +0200 (CEST) Subject: [Live-devel] Porting of live555 Streaming on Windows CE Message-ID: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> Hi, I'm working in porting the live555 on windows CE system. I was able to compile and test the library on WinCE but to do that I've made some small modification in the code. In particular I've used the libce library to resolve some compilation error on the flowing functions: _fileno: has different signature under WinCE abort: is not available under WinCE read: is not available under WinCE So I'm wondering if it is always available a port on WinCE under LGPL license, this allow me to use the library without change the source code. Regards Daniele Santanche' Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale pi? di uno spot in TV. Per ogni nuovo abbonato 30 ? di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/ From finlayson at live555.com Tue Jul 24 07:43:58 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Jul 2012 07:43:58 -0700 Subject: [Live-devel] Porting of live555 Streaming on Windows CE In-Reply-To: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> References: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> Message-ID: > In particular I've used the libce > library to resolve some compilation > error on the flowing functions: > > > _fileno: has different signature under WinCE > abort: is not available > under WinCE > read: is not available under WinCE That's strange. Several other people have built the code for WinCE, but nobody else has reported having to modify the supplied code in order to do so. > So I'm wondering if it > is always available a port on WinCE under LGPL > license, this allow me > to use the library without change the source > code. I don't understand this question. The code is licensed under LGPL (regardiess of the operating system on which you use it). This means that if you modify the supplied code, and then release a product based on these modifications, then you are required to also make your modified source code available. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Tue Jul 24 08:15:32 2012 From: sidprice at softtools.com (Sid Price) Date: Tue, 24 Jul 2012 09:15:32 -0600 Subject: [Live-devel] Porting of live555 Streaming on Windows CE In-Reply-To: References: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> Message-ID: <003f01cd69af$2c2d6c20$84884460$@softtools.com> I can confirm the same issues when compiling for Windows Compact 7. The problem with _fileno is that it returns "void *" and "makeSocketNonBlocking" and "turnOffBackgroundReadHandling"takes a "socket" parameter that is defined as "int". The MS compiler for Windows Compact 7 considers this attempt at an implicit cast as an error. Indeed even an explicit cast is a doubtful fix since depending upon architecture of the target CPU the size of a pointer and an "int" may not be the same and could under some circumstances cause the truncation of the value returned by "fileno". The standard "C" library for Windows Compact 7 does not have functions "abort" or "read". I have addressed this by creating my own methods. At this time the only resolution I have for the cast issue is to explicitly cast the return of "fileno". Not ideal from a maintenance perspective but the only choice at this time. Is it possible to update the code to address this implicit cast? Thanks, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, July 24, 2012 8:44 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Porting of live555 Streaming on Windows CE In particular I've used the libce library to resolve some compilation error on the flowing functions: _fileno: has different signature under WinCE abort: is not available under WinCE read: is not available under WinCE That's strange. Several other people have built the code for WinCE, but nobody else has reported having to modify the supplied code in order to do so. So I'm wondering if it is always available a port on WinCE under LGPL license, this allow me to use the library without change the source code. I don't understand this question. The code is licensed under LGPL (regardiess of the operating system on which you use it). This means that if you modify the supplied code, and then release a product based on these modifications, then you are required to also make your modified source code available. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5650 bytes Desc: not available URL: From finlayson at live555.com Tue Jul 24 08:36:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Jul 2012 08:36:54 -0700 Subject: [Live-devel] Porting of live555 Streaming on Windows CE In-Reply-To: <003f01cd69af$2c2d6c20$84884460$@softtools.com> References: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> <003f01cd69af$2c2d6c20$84884460$@softtools.com> Message-ID: > The problem with _fileno is that it returns "void *" and > "makeSocketNonBlocking" and "turnOffBackgroundReadHandling"takes a "socket" > parameter that is defined as "int". Note the difference between "fileno()" - a standard C library function that should always returns an "int" (even, I hope, on WinCE) - and "_fileno()" (i.e., with a preceding "_"), which is a Windows-specific function which we use only in Windows-specific code (in the files "InputFile.cpp" and "OutputFile.cpp"). Note also that we use "_fileno()" only inside other Windows-specific functions "_setmode()", "_lseeki64()", and "_telli64()", so I'm surprised if you're seeing problems there. So is the problem only with "_fileno()" (in which case, please propose a patch to the Windows-specific code in "InputFile.cpp" and "OutputFile.cpp")? Or are you saying that Microsoft has redefined the return type of the standard C library function "fileno()" as well?? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Tue Jul 24 09:22:48 2012 From: sidprice at softtools.com (Sid Price) Date: Tue, 24 Jul 2012 10:22:48 -0600 Subject: [Live-devel] Porting of live555 Streaming on Windows CE In-Reply-To: References: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> <003f01cd69af$2c2d6c20$84884460$@softtools.com> Message-ID: <005d01cd69b8$91914c90$b4b3e5b0$@softtools.com> Thanks Ross, I think we are getting close to the issue here because in stdlib.h I see the following code: #if !__STDC__ /* Non-ANSI names for compatibility */ #define fcloseall _fcloseall #define fileno _fileno #define flushall _flushall #endif /* !__STDC__ */ Notice this maps "fileno" to "_fileno". And therefore since "_fopen" returns (void *) we have an implicit cast, and hence the error. If I define __STDC__ then "fileno" is undefined. According to the help for the compiler this, and other, POSIX functions are deprecated in favor of the ANSI function. Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, July 24, 2012 9:37 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Porting of live555 Streaming on Windows CE The problem with _fileno is that it returns "void *" and "makeSocketNonBlocking" and "turnOffBackgroundReadHandling"takes a "socket" parameter that is defined as "int". Note the difference between "fileno()" - a standard C library function that should always returns an "int" (even, I hope, on WinCE) - and "_fileno()" (i.e., with a preceding "_"), which is a Windows-specific function which we use only in Windows-specific code (in the files "InputFile.cpp" and "OutputFile.cpp"). Note also that we use "_fileno()" only inside other Windows-specific functions "_setmode()", "_lseeki64()", and "_telli64()", so I'm surprised if you're seeing problems there. So is the problem only with "_fileno()" (in which case, please propose a patch to the Windows-specific code in "InputFile.cpp" and "OutputFile.cpp")? Or are you saying that Microsoft has redefined the return type of the standard C library function "fileno()" as well?? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5862 bytes Desc: not available URL: From finlayson at live555.com Tue Jul 24 13:20:21 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Jul 2012 13:20:21 -0700 Subject: [Live-devel] Porting of live555 Streaming on Windows CE In-Reply-To: <005d01cd69b8$91914c90$b4b3e5b0$@softtools.com> References: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> <003f01cd69af$2c2d6c20$84884460$@softtools.com> <005d01cd69b8$91914c90$b4b3e5b0$@softtools.com> Message-ID: <512F41EB-5401-4908-A398-E51A358D26F6@live555.com> OK, it turns out that the problem is not as bad as I had first thought. The code (in the LIVE555 library) that calls "fileno()" and "read()" turns out to not be needed for Windows at all, because it's used only to implement asynchronous file reading (which is not supported in Windows). I have now added some "#ifdef"s to ensure that your compiler will now never even see this code. (I'm assuming that you're compiling with _WIN32_WCE defined.) I have now installed a new version (2012.07.24) of the "LIVE555 Streaming Media" code that should fix this. (The code still, however, assumes that an "abort()" function is defined. If it's not defined for you, then you'll need to write your own.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Tue Jul 24 13:52:49 2012 From: sidprice at softtools.com (Sid Price) Date: Tue, 24 Jul 2012 14:52:49 -0600 Subject: [Live-devel] Porting of live555 Streaming on Windows CE In-Reply-To: <512F41EB-5401-4908-A398-E51A358D26F6@live555.com> References: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> <003f01cd69af$2c2d6c20$84884460$@softtools.com> <005d01cd69b8$91914c90$b4b3e5b0$@softtools.com> <512F41EB-5401-4908-A398-E51A358D26F6@live555.com> Message-ID: <009a01cd69de$4a390740$deab15c0$@softtools.com> Thank you Ross, I will download and take it for a spin, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, July 24, 2012 2:20 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Porting of live555 Streaming on Windows CE OK, it turns out that the problem is not as bad as I had first thought. The code (in the LIVE555 library) that calls "fileno()" and "read()" turns out to not be needed for Windows at all, because it's used only to implement asynchronous file reading (which is not supported in Windows). I have now added some "#ifdef"s to ensure that your compiler will now never even see this code. (I'm assuming that you're compiling with _WIN32_WCE defined.) I have now installed a new version (2012.07.24) of the "LIVE555 Streaming Media" code that should fix this. (The code still, however, assumes that an "abort()" function is defined. If it's not defined for you, then you'll need to write your own.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.lc at vaelsys.com Tue Jul 24 23:37:18 2012 From: jesus.lc at vaelsys.com (=?ISO-8859-1?Q?Jes=FAs_Legan=E9s?=) Date: Wed, 25 Jul 2012 08:37:18 +0200 Subject: [Live-devel] Unitialized value In-Reply-To: <43DA4E2A-25FD-4F2C-8AAA-3B4834B01C4B@live555.com> References: <43DA4E2A-25FD-4F2C-8AAA-3B4834B01C4B@live555.com> Message-ID: Welcome :-) In fact, i have done it on my copy of the code and some SEGFAULTs where fixed just doing this... :-D It would be good (if you have time) to pass Valgrind on the library to catch more things like this, since i'm getting some other messages suspect to have the same problem... :-/ 2012/7/24 Ross Finlayson : > Thanks. This will be fixed in the next release of the software. > > 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 > -- Jes?s Legan?s Combarro Software developer at Vaelsys From techvalens.testing at gmail.com Wed Jul 25 03:14:12 2012 From: techvalens.testing at gmail.com (techvalens testing) Date: Wed, 25 Jul 2012 15:44:12 +0530 Subject: [Live-devel] Need help to use testRTSPClient in Java Message-ID: Hi, I want to use this library in my Java project for video streaming, please suggest me how to port this library into my Java Project. -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Wed Jul 25 14:14:43 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Wed, 25 Jul 2012 21:14:43 +0000 Subject: [Live-devel] Recording time available? Message-ID: Is there a way to get the recording timestamp for stored content? When looking at the presentation time that is received with each frame I see that it is matching the current time of the server, but when playing back an archived stream I'm interested in when it was recorded. Can that be found somewhere? /Claes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From sidprice at softtools.com Wed Jul 25 15:05:05 2012 From: sidprice at softtools.com (Sid Price) Date: Wed, 25 Jul 2012 16:05:05 -0600 Subject: [Live-devel] Porting of live555 Streaming on Windows CE In-Reply-To: <512F41EB-5401-4908-A398-E51A358D26F6@live555.com> References: <22115881.87081343139494516.JavaMail.defaultUser@defaultHost> <003f01cd69af$2c2d6c20$84884460$@softtools.com> <005d01cd69b8$91914c90$b4b3e5b0$@softtools.com> <512F41EB-5401-4908-A398-E51A358D26F6@live555.com> Message-ID: <00a701cd6ab1$8cd41f80$a67c5e80$@softtools.com> Nice work Ross, I downloaded the library and with my "abort" function added it built just fine. I am doing some testing with the OnDemandRTSPServer. Thanks, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, July 24, 2012 2:20 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Porting of live555 Streaming on Windows CE OK, it turns out that the problem is not as bad as I had first thought. The code (in the LIVE555 library) that calls "fileno()" and "read()" turns out to not be needed for Windows at all, because it's used only to implement asynchronous file reading (which is not supported in Windows). I have now added some "#ifdef"s to ensure that your compiler will now never even see this code. (I'm assuming that you're compiling with _WIN32_WCE defined.) I have now installed a new version (2012.07.24) of the "LIVE555 Streaming Media" code that should fix this. (The code still, however, assumes that an "abort()" function is defined. If it's not defined for you, then you'll need to write your own.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 25 16:05:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Jul 2012 16:05:24 -0700 Subject: [Live-devel] Recording time available? In-Reply-To: References: Message-ID: <467BA9D2-CD7F-4657-8097-86E2D12D375D@live555.com> > Is there a way to get the recording timestamp for stored content? > > When looking at the presentation time that is received with each frame I see > that it is matching the current time of the server, but when playing back an > archived stream I'm interested in when it was recorded. Can that be found > somewhere? I find your question confusing, because it wasn't really clear how it relates to our software. Could you please clarify your question, explaining in particular how you are using our software? (Remember that our software can be used to build RTSP clients, RTSP servers, RTSP proxy servers, and other things.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Wed Jul 25 17:09:48 2012 From: sidprice at softtools.com (Sid Price) Date: Wed, 25 Jul 2012 18:09:48 -0600 Subject: [Live-devel] Streaming a WAV file In-Reply-To: References: <020a01cd3f8c$7d762b00$78628100$@softtools.com> Message-ID: <00c501cd6ac2$f9761ec0$ec625c40$@softtools.com> Hi Ross, Sorry it took so long to get back to this. I reworked the front end of the WAVAudioFileSource Constructor to cope with the possible variety of subchunks in the "WAVE" chunck. It is passed below. Unfortunately the sample WAV file I have is copyright material and I am not comfortable sharing it. I will search to find a suitable WAV file. WAVAudioFileSource::WAVAudioFileSource(UsageEnvironment& env, FILE* fid) : AudioInputDevice(env, 0, 0, 0, 0)/* set the real parameters later */, fFid(fid), fFidIsSeekable(False), fLastPlayTime(0), fHaveStartedReading(False), fWAVHeaderSize(0), fFileSize(0), fScaleFactor(1), fLimitNumBytesToStream(False), fNumBytesToStream(0), fAudioFormat(WA_UNKNOWN) { // Check the WAV file header for validity. // Note: The following web pages contain info about the WAV format: // http://www.ringthis.com/dev/wave_format.htm // http://www.lightlink.com/tjweber/StripWav/Canon.html // http://www.wotsit.org/list.asp?al=W Boolean success = False; // until we learn otherwise do { int iStatus = 1; // 0 means we can procede after finding "fmt " // 1 means keep going // -1 means error occured { unsigned int uiTemp, uiSubchunkSize ; // // Attempt to read "RIFF" // if (!get4Bytes(fid, uiTemp)) break; if (uiTemp != 0x46464952) break ; if (!skipBytes(fid, 4)) break; // // Attempt to read "WAVE" // if (!get4Bytes(fid, uiTemp)) break; if (uiTemp != 0x45564157) break ; // // Loop until the "fmt " subchunk is found // while(iStatus == 1) { if (get4Bytes(fid, uiTemp)) { // // Is it "fmt "? // if (uiTemp != 0x20746d66) { // // Skip this subchunk // if (get4Bytes(fid, uiSubchunkSize)) { if (!skipBytes(fid, uiSubchunkSize)) { iStatus = -1 ; } } else { iStatus = -1 ; } } else { // // Found the "fmt " subchunk" ... exit loop // break ; } } else { iStatus = -1 ; // Error give up } } } if(iStatus == -1) break ; // error in parsing //// RIFF Chunk: //if (nextc != 'R' || nextc != 'I' || nextc != 'F' || nextc != 'F') break; //if (!skipBytes(fid, 4)) break; //if (nextc != 'W' || nextc != 'A' || nextc != 'V' || nextc != 'E') break; //// FORMAT Chunk: //if (nextc != 'f' || nextc != 'm' || nextc != 't' || nextc != ' ') break; unsigned formatLength; if (!get4Bytes(fid, formatLength)) break; unsigned short audioFormat; The balance of the method remains the same. The new code simply skips and subchunk other than "fmt " Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, June 06, 2012 3:43 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Streaming a WAV file I am running the OnDemandRTSPServer test application with WAV files and it seems that the WAV file processing expects the first SubChunk of the file to always be the "fmt " SubChunk. This is not the case for the files I am using, they have other SubChunks, e.g. "LIST". What is the best way to get this into the library? Should I implement and submit my changes to you? Yes, if you can. (The change will most likely be to the file "liveMedia/WAVAudioFileSource.cpp".) For future reference, it would also be useful to get an example of a WAV file like this. Could you please put one on a web server, and send us the URL, so we can download it? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 25 18:13:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Jul 2012 18:13:45 -0700 Subject: [Live-devel] Unitialized value In-Reply-To: References: <43DA4E2A-25FD-4F2C-8AAA-3B4834B01C4B@live555.com> Message-ID: <54F16015-B866-4E31-8643-AB9B690978D4@live555.com> > It would be good (if you have time) to pass Valgrind on the library to > catch more things like this, since i'm getting some other messages > suspect to have the same problem... :-/ "valgrind" can be a useful tool, but unfortunately (at least, whenever I've run it) produces *many* 'false positives'. I.e., it complains about a lot of things that aren't really errors. Nonetheless, if anyone finds any more real errors using "valgrind" (or other such tools), then please let us know. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 25 18:26:41 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Jul 2012 18:26:41 -0700 Subject: [Live-devel] Streaming a WAV file In-Reply-To: <00c501cd6ac2$f9761ec0$ec625c40$@softtools.com> References: <020a01cd3f8c$7d762b00$78628100$@softtools.com> <00c501cd6ac2$f9761ec0$ec625c40$@softtools.com> Message-ID: <6052E309-DE25-4EBB-B9B1-B17783F93047@live555.com> Thanks. This will be included in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Wed Jul 25 19:37:08 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Thu, 26 Jul 2012 02:37:08 +0000 Subject: [Live-devel] Recording time available? In-Reply-To: <467BA9D2-CD7F-4657-8097-86E2D12D375D@live555.com> References: , <467BA9D2-CD7F-4657-8097-86E2D12D375D@live555.com> Message-ID: I find your question confusing, because it wasn't really clear how it relates to our software. Could you please clarify your question, explaining in particular how you are using our software? (Remember that our software can be used to build RTSP clients, RTSP servers, RTSP proxy servers, and other things.) I've built a RTSP client using your library, so my question is related to what information that is passed from the server to the client. When I stream an archive file (i.e. non-live) from a RTSP-server ("Cisco Video Surveillance Media Server" in this case) it would great to be able to get a timestamp indicating when it was recorded. For live streams such a field would of course be the current server time. Is there any other timestamp available at all besides presentation time? I have been trying to research if such a timestamp field is part of the RTSP-protocol or not, but I haven't found anything, so that is one reason I ask before spending too much time looking into the code. Since it's kind of essential information, at least for surveillance, I would hope it's part of the specification. I know it's possible to get this information with the Cisco bundled software, but it can of course be some third party added feature. /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 25 19:59:31 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Jul 2012 19:59:31 -0700 Subject: [Live-devel] Recording time available? In-Reply-To: References: , <467BA9D2-CD7F-4657-8097-86E2D12D375D@live555.com> Message-ID: <8DDA9954-7CC9-4498-B010-D9CA65909E41@live555.com> > I've built a RTSP client using your library, so my question is related to what information that is passed from the server to the client. When I stream an archive file (i.e. non-live) from a RTSP-server ("Cisco Video Surveillance Media Server" in this case) it would great to be able to get a timestamp indicating when it was recorded. For live streams such a field would of course be the current server time. Is there any other timestamp available at all besides presentation time? > > No. (And even the presentation time should be considered, by the client, to be only a 'relative' time stamp - not an absolute time in any time scale.) However, depending upon the specific codec(s) that you are using, it *might* be possible to embed extra information (such as a different kind of timestamp) within the encoded media itself (i.e., invisible to RTP or our software). Plus, of course, the server could put (static, one-time) information into the stream's SDP description (e.g., the "i=" or "s=" lines). if so, then this information would be available to your client. But in either case, this depends upon whatever the server decides to do. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboom at channelislands.com Thu Jul 26 12:14:58 2012 From: mboom at channelislands.com (Michael L. Boom) Date: Thu, 26 Jul 2012 12:14:58 -0700 Subject: [Live-devel] Range Header In-Reply-To: References: <8CE79E3CB2664753A3AA216BB47D82A7@Work><51CECC72-536F-4271-B8D1-52585B908E67@live555.com><527BA5F8C28A4D9982F00935D661DF2B@Work><6E9B28C2-B5CF-4637-B708-ED6B496F9C30@live555.com><34E799C37151466AA8D7E20E680FC8D7@Work> Message-ID: Just wondering if this bug is a priority or if it may be a while. From: Ross Finlayson Sent: Monday, July 23, 2012 6:20 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Range Header Ok. I tried your test program. I tried with scale of 1 and 2. If the client sends "Range: npt=30.000-60.000" the server plays starting at 30 seconds into the clip (clip timing information - not wall time) and plays for 30 seconds wall time (which for scale 2 will be 60 seconds of clip time). Shouldn't the server only stream 30 seconds according to the PTS/DTS and ignore the wall clock time for range not equal to 1? Yes. This is a bug that I'll need to fix. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 26 17:47:14 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jul 2012 17:47:14 -0700 Subject: [Live-devel] Updated RTSP server implementation to support multiple TCP connections per session - new experimental release Message-ID: <575A2784-A62B-4960-B762-100188C7DA6A@live555.com> (First, if you are not using a RTSP server at all in your application, you can ignore the rest of this email.) I have made a major update to the RTSP server implementation. A single RTSP client session (i.e, the streaming of one particular stream to one particular client) can now use an arbitrary number (>=1) of TCP connections. E.g., there can now be one TCP connection for the "DESCRIBE"; another TCP connection for each "SETUP"; another TCP connection for "PLAY", etc. (Of course, this applies only to RTP/UDP sessions; RTP/TCP sessions have to use the same TCP connection, from "SETUP" through "TEARDOWN".) Similarly, a single TCP connection can now be used for more than one session (for the same client, of course). (Despite this, our own RTSP *client* implementation continues to use a single TCP connection for each session.) The new RTSP server implementation does this by separating 'client connection' from 'client session'. The "RTSPServer" class now has two member classes: "RTSPServer::RTSPClientConnection" (for a single TCP connection), and "RTSPServer::RTSPClientSession" (for a single client session, possibly used by multiple TCP connections). You can, if you wish, subclass these two classes, along with subclassing "RTSPServer" itself. I have also improved the way that the "RTSPServer" class manages "ServerMediaSession" objects. (Recall that a "ServerMediaSession" describes a single media stream source (possibly with 'subsessions' for audio, video, etc.), regardless of how many clients happen to be currently receiving it.) - As before, the "RTSPServer::removeServerMediaSession()" function removes a "ServerMediaSession" object from the server, thereby making it inaccessible to new clients, but does not stop any ongoing streaming to existing clients. - A new function "RTSPServer::deleteServerMediaSession()" removes (and deletes) a "ServerMediaSession" object from the server, *and also* stops any streaming to existing clients. - A new function "RTSPServer::closeAllClientSessionsForServerMediaSession()" stops any streaming (for a specified "ServerMediaSession" object) to existing clients, but leaves the "ServerMediaSession" object on the server, so that new clients can still access it. - The "RTSPServer" destructor now removes and deletes all "RTSPClientConnection" and "RTSPClientSession" objects, and thereby also stops any existing ongoing streams. So, if you wish, you can call "Medium::close()" on your "RTSPServer" object, knowing that this will automatically stop all existing streaming, and reclaim all of its objects. Because these changes are substantial, and possibly have introduced some bugs, I have done something unusual, by making the new source code release an 'experimental' release. It's available at: http://www.live555.com/liveMedia/public/live555-experimental.tgz Eventually, however (possibly just within a week or so), this new release will no longer be experimental; it will become the lone supported "LIVE555 Streaming Media" release. Therefore, if you're a developer who uses a RTSP server in your application, you are encouraged to download and test the new experimental release, and report back on any problems that you might find. Note, in particular, that if you have subclassed "RTSPServer", then you should download and test the new experimental version sooner rather than later, because the API for subclassing has changed (the API for creating new "RTSPClientSession"s has changed, and there's now a new "RTSPClientConnection" class as well). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 26 18:21:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jul 2012 18:21:02 -0700 Subject: [Live-devel] Range Header In-Reply-To: References: <8CE79E3CB2664753A3AA216BB47D82A7@Work><51CECC72-536F-4271-B8D1-52585B908E67@live555.com><527BA5F8C28A4D9982F00935D661DF2B@Work><6E9B28C2-B5CF-4637-B708-ED6B496F9C30@live555.com><34E799C37151466AA8D7E20E680FC8D7@Work> Message-ID: > Just wondering if this bug is a priority or if it may be a while. The fact that I consider it a bug automatically makes it a priority, but I can't (and won't) give an ETA (and asking about this will only delay it more :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssoffiiaa at hotmail.com Wed Jul 25 23:57:29 2012 From: ssoffiiaa at hotmail.com (sofia Mora) Date: Thu, 26 Jul 2012 08:57:29 +0200 Subject: [Live-devel] How to program a server by using a rstp address Message-ID: Hi everyone, First all, Sorry for my bad english but I need help with this I have been studying testOnDemandRTSPServer code and I want to do streaming by taking input from a live source by using a rtsp address. I have read that I have to modify OnDemandServerMediaSubsession and createNewStreamSource() and createNewRTPSink() functions. I don't know how to do this. I don't know how to start with this. I have been searching information via Internet but I haven't found anything. I'm new on this. Thanks for all. Sophie -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.santanche at tiscali.it Thu Jul 26 00:49:09 2012 From: d.santanche at tiscali.it (d.santanche at tiscali.it) Date: Thu, 26 Jul 2012 09:49:09 +0200 (CEST) Subject: [Live-devel] R: Re: Porting of live555 Streaming on Windows CE Message-ID: <9056178.19821343288949460.JavaMail.defaultUser@defaultHost> Hi Ross, I've downloaded the version live555 2012.07.24, I've implemented my abort() function and now quite all compilation issues are solved. The only one compilation error now is related to the stat. h file which is not available under WindowsCE: RTSPServerSupportingHTTPStreaming.cpp .... fatal error C1083: Cannot open include file: 'sys/stat.h': No such file or directory The stat.h is needed in the implementation of the function: static char const* lastModifiedHeader(char const* fileName) which returns the HTTP header "Last-Modified". So I've to modified the source code providing an implementation of lastModifiedHeader() function for WinCE. Doing that it seems to work for me. Daniele ----Messaggio originale---- Da: finlayson at live555.com Data: 24/07/2012 22.20 A: "LIVE555 Streaming Media - development & use" Ogg: Re: [Live- devel] Porting of live555 Streaming on Windows CE OK, it turns out that the problem is not as bad as I had first thought. The code (in the LIVE555 library) that calls "fileno()" and "read()" turns out to not be needed for Windows at all, because it's used only to implement asynchronous file reading (which is not supported in Windows). I have now added some "#ifdef"s to ensure that your compiler will now never even see this code. (I'm assuming that you're compiling with _WIN32_WCE defined.) I have now installed a new version (2012.07.24) of the "LIVE555 Streaming Media" code that should fix this. (The code still, however, assumes that an "abort()" function is defined. If it's not defined for you, then you'll need to write your own.) 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 Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale pi? di uno spot in TV. Per ogni nuovo abbonato 30 ? di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/ From warren at etr-usa.com Thu Jul 26 22:39:51 2012 From: warren at etr-usa.com (Warren Young) Date: Thu, 26 Jul 2012 23:39:51 -0600 Subject: [Live-devel] How to program a server by using a rstp address In-Reply-To: References: Message-ID: <501229A7.8070805@etr-usa.com> On 7/26/2012 12:57 AM, sofia Mora wrote: > > I have been studying testOnDemandRTSPServer code and I want to do > streaming by taking input from a live source by using a rtsp address. It sounds like you're trying to reinvent the Live555 proxy server: http://www.live555.com/proxyServer/ > have read that I have to modify OnDemandServerMediaSubsession and > createNewStreamSource() and createNewRTPSink() functions. I don't know > how to do this. If it turns out that you really do need to create a custom server, because the proxy server doesn't do what you want, I'd suggest grepping the examples' source tree for these functions and seeing how they implement these methods. From finlayson at live555.com Thu Jul 26 22:45:42 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jul 2012 22:45:42 -0700 Subject: [Live-devel] How to program a server by using a rstp address In-Reply-To: <501229A7.8070805@etr-usa.com> References: <501229A7.8070805@etr-usa.com> Message-ID: <52CC8321-D907-4F78-BB60-412BD8D55DB5@live555.com> >> I have been studying testOnDemandRTSPServer code and I want to do >> streaming by taking input from a live source by using a rtsp address. > > It sounds like you're trying to reinvent the Live555 proxy server: > > http://www.live555.com/proxyServer/ Agreed. > If it turns out that you really do need to create a custom server, because the proxy server doesn't do what you want I'm curious as to why you think this? From the original poster's description, it sounds like the "LIVE555 Proxy Server" is just what she wants - especially as it requires no programming. (This software is intended for experienced programmers only.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Jul 26 22:45:41 2012 From: warren at etr-usa.com (Warren Young) Date: Thu, 26 Jul 2012 23:45:41 -0600 Subject: [Live-devel] R: Re: Porting of live555 Streaming on Windows CE In-Reply-To: <9056178.19821343288949460.JavaMail.defaultUser@defaultHost> References: <9056178.19821343288949460.JavaMail.defaultUser@defaultHost> Message-ID: <50122B05.30305@etr-usa.com> On 7/26/2012 1:49 AM, d.santanche at tiscali.it wrote: > stat.h file which is not available under WindowsCE: "libce plugs the holes in Microsoft Visual C++ runtime for Windows CE, making it more compatible with ANSI C." https://code.google.com/p/libce/ From techvalens.testing at gmail.com Thu Jul 26 10:57:15 2012 From: techvalens.testing at gmail.com (techvalens testing) Date: Thu, 26 Jul 2012 23:27:15 +0530 Subject: [Live-devel] Error in Local.hh Message-ID: Hi, When i use testRTSPClient.cpp as model and making RTSPClient then i got Error in Local.hh as follow /Locale.hh:47:123: error: xlocale.h: No such file or directory /Locale.hh:62: error: 'locale_t' does not name a type Please suggest me how to remove these error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Jul 26 23:25:16 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 27 Jul 2012 00:25:16 -0600 Subject: [Live-devel] How to program a server by using a rstp address In-Reply-To: <52CC8321-D907-4F78-BB60-412BD8D55DB5@live555.com> References: <501229A7.8070805@etr-usa.com> <52CC8321-D907-4F78-BB60-412BD8D55DB5@live555.com> Message-ID: <5012344C.3060701@etr-usa.com> On 7/26/2012 11:45 PM, Ross Finlayson wrote: >> If it turns out that you really do need to create a custom server, >> because the proxy server doesn't do what you want > > I'm curious as to why you think this? Just covering bases. It wouldn't be the first time I read a vague question and answered the one I thought was being asked instead of the one the OP thought she was asking. :) If you re-read the question, all it really says is that the source is RTSP. It doesn't actually say she wants it echoed *back out* as RTSP. We only see an implication of that, from the fact that she was studying the sample RTSP server. From warren at etr-usa.com Thu Jul 26 23:31:40 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 27 Jul 2012 00:31:40 -0600 Subject: [Live-devel] Error in Local.hh In-Reply-To: References: Message-ID: <501235CC.2090807@etr-usa.com> On 7/26/2012 11:57 AM, techvalens testing wrote: > > /Locale.hh:47:123: error: xlocale.h: No such file or directory You probably passed the wrong platform name to genMakefiles, but that's only a guess, because you haven't said what your platform is, or what you passed. If your actual platform is indeed the right type for the one you selected with genMakefiles, it probably needs "-DXLOCALE_NOT_USED=1" added. But, since the last change needed of that sort was done a couple of months ago, the odds of that aren't good. Unless, that is, you're trying to build a months-old version of Live555 on Cygwin. From abmadaan at yahoo.com Thu Jul 26 20:34:32 2012 From: abmadaan at yahoo.com (Abhishek Madaan) Date: Thu, 26 Jul 2012 20:34:32 -0700 (PDT) Subject: [Live-devel] How to know if connection established? Message-ID: <1343360072.43763.YahooMailNeo@web114516.mail.gq1.yahoo.com> Hi Ross, ?????????????? I able to make MFC GUI application and able to solve all the issues. The only issue i have (due to lack of my knowledge of your library) that how I find out if the connection is established correctly or not. What I mean that if the customer add wrong IP Address, how do we find out the connection successfully created or not. I tried with testRTSP program, where doEventLoop loop runs once and program exits. But my program is a multithreaded application, where I am receiving video on one thread and customer can add IP Address in GUI thread. So, I want to give notification if the connection is not created successfully so that customers can correct the IP Address. Also, is there event fires when we lost connection after the connection is already established? Thanks for your help Regards, Abhishek Madaan -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhg84 at gmail.com Thu Jul 26 23:20:25 2012 From: saurabhg84 at gmail.com (Saurabh Gandhi) Date: Fri, 27 Jul 2012 11:50:25 +0530 Subject: [Live-devel] Network congestion while using Live555 framework (resending with proper formatting) Message-ID: Hello Ross, I am resending this mail since the earlier mail formatting was improper. We have created a multi-threaded framework (using Qt) to test live555 for one of our projects. For this, we are using: 1. Live555 proxy server for re-streaming live streams from 16 IP cameras 2. OpenRTSP for recording of live RTSP streams coming from 16 IP cameras The system worked fine for over two days (we monitored the recorded clips that were generated periodically as well as built a test client to monitor the proxy streams being generated by the proxy server). However, after two days we experienced a network congestion. We tried to monitor what was happening using wire-shark (refer attachment). Does this have any relation to live555 framework, since that was the sole application running on the PC which was related to network. We have been able to reproduce this problem multiple times and each time this problem happens we see ARP packets on the wire-shark window. Any ideas what might be happening. Awaiting your response. -- Regards, Saurabh Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: network_congestion.png Type: image/png Size: 188960 bytes Desc: not available URL: From finlayson at live555.com Fri Jul 27 02:10:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jul 2012 02:10:02 -0700 Subject: [Live-devel] How to know if connection established? In-Reply-To: <1343360072.43763.YahooMailNeo@web114516.mail.gq1.yahoo.com> References: <1343360072.43763.YahooMailNeo@web114516.mail.gq1.yahoo.com> Message-ID: > I able to make MFC GUI application and able to solve all the issues. The only issue i have (due to lack of my knowledge of your library) that how I find out if the connection is established correctly or not. What I mean that if the customer add wrong IP Address, how do we find out the connection successfully created or not. I tried with testRTSP program, where doEventLoop loop runs once and program exits. But my program is a multithreaded application, where I am receiving video on one thread and customer can add IP Address in GUI thread. So, I want to give notification if the connection is not created successfully so that customers can correct the IP Address. Also, is there event fires when we lost connection after the connection is already established? Your question is confusing, but I'm guessing that you're referring to using our software as a RTSP client. Note that - with our "RTSPClient" class - the RTSP (TCP) connection is not attempted until the first time that a RTSP command is sent. So, to test whether the connection gets established OK, just (try to) send a RTSP "OPTIONS" command, by calling RTSPClient::sendOptionsCommand( ... ) with a 'response handler' function as parameter. The "resultCode" value in the resulting handler function call will tell you whether or not the command succeeded. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 27 02:14:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jul 2012 02:14:03 -0700 Subject: [Live-devel] Network congestion while using Live555 framework (resending with proper formatting) In-Reply-To: References: Message-ID: > We have created a multi-threaded framework (using Qt) to test live555 for one of our projects. Do 'we' not have our own domain name? :-) > For this, we are using: > Live555 proxy server for re-streaming live streams from 16 IP cameras > OpenRTSP for recording of live RTSP streams coming from 16 IP cameras > The system worked fine for over two days (we monitored the recorded clips that were generated periodically as well as built a test client to monitor the proxy streams being generated by the proxy server). However, after two days we experienced a network congestion. We tried to monitor what was happening using wire-shark (refer attachment). > > Does this have any relation to live555 framework Unfortunately it's just not possible to answer questions like this, because it's far from clear what is happening on your system. I'm afraid you're just going to have to track this down yourself... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.orry at em-sys.fr Fri Jul 27 04:26:01 2012 From: lionel.orry at em-sys.fr (Lionel Orry) Date: Fri, 27 Jul 2012 13:26:01 +0200 Subject: [Live-devel] Updated RTSP server implementation to support multiple TCP connections per session - new experimental release In-Reply-To: <575A2784-A62B-4960-B762-100188C7DA6A@live555.com> References: <575A2784-A62B-4960-B762-100188C7DA6A@live555.com> Message-ID: <1343388361.3000.27.camel@localhost.localdomain> Dear Ross, Thank you very much for this hard and valuable work. I am trying to migrate my current development on this branch. This is working well for now, though I have not tested the independence between RTSP sessions and TCP connections yet. I am however facing some inheritance/relationship issues that I will try to explain. I have subclassed RTSPServerSupportingHTTPStreaming, RTSPServer::RTSPClientSession and RTSPServer::RTSPClientConnection classes for my needs, overriding virtual methods. I am trying, in the SETUP phase for example, to augment the response buffer with specific headers. Here is an outline of what I am doing currently: ------------------------------------------------------------------------ // Declaration class MyOwnRTSPServer: public RTSPServerSupportingHTTPStreaming { public: class RTSPServerConnection: public RTSPServer::RTSPServerConnection { // [...] }; class RTSPServerSession: public RTSPServer::RTSPServerSession { protected: virtual void handleCmd_SETUP(RTSPServer::RTSPClientConnection* ourClientConnection, char const* urlPreSuffix, char const* urlSuffix, char const* fullRequestStr); }; }; // Implementation void MyOwnRTSPServer::RTSPServerSession ::handleCmd_SETUP(RTSPServer::RTSPClientConnection* ourClientConnection, char const* urlPreSuffix, char const* urlSuffix, char const* fullRequestStr) { // Doing specific stuff here... // calling original handler RTSPServer::RTSPClientSession::handleCmd_SETUP(ourClientConnection, urlPreSuffix, urlSuffix, fullRequestStr); // Trying to append lines to responseBuffer char *lastLine = strstr( (const char*)ourClientConnection->fResponseBuffer, "\r\n\r\n"); if (lastLine==NULL) { envir() << "ERROR: last line of response buffer not found!\n"; return; } sprintf(lastLine, "\r\nmyField: %d\r\n\r\n", myValue); } ------------------------------------------------------------------------ The problem is, if I write it as-is, the compiler (GCC) tells me: include/RTSPServer.hh:196: error: ?unsigned char RTSPServer::RTSPClientConnection::fResponseBuffer [10000]? is protected even though I tried to do my best to correctly declare friend classes and such. I found a working solution but I am not extremely happy about it, and I am searching for suggestions: I declared a new pointer with my own RTSPClientConnection type, and I did a dynamic_cast of the original Connection instance: ------------------------------------------------------------------------ void MyOwnRTSPServer::RTSPServerSession ::handleCmd_SETUP(RTSPServer::RTSPClientConnection* ourClientConnection, char const* urlPreSuffix, char const* urlSuffix, char const* fullRequestStr) { RTSPClientConnection* conn = dynamic_cast( ourClientConnection); // calling original handler RTSPServer::RTSPClientSession::handleCmd_SETUP(ourClientConnection, urlPreSuffix, urlSuffix, fullRequestStr); // Trying to append lines to responseBuffer char *lastLine = strstr( (const char*)conn->fResponseBuffer, // <---- I use 'conn' here "\r\n\r\n"); // rest of code... } ------------------------------------------------------------------------ The code above compiles and works fine. My first attempt was to declare the handler with the first parameter of type MyOwnRTSPServer::RTSPClientConnection, but it would not override the original method because the prototype would be different. Does any of you have an idea of how to make that look good ? Thanks for your inputs, Lionel On Thu, 2012-07-26 at 17:47 -0700, Ross Finlayson wrote: > (First, if you are not using a RTSP server at all in your application, > you can ignore the rest of this email.) > > > I have made a major update to the RTSP server implementation. A > single RTSP client session (i.e, the streaming of one particular > stream to one particular client) can now use an arbitrary number (>=1) > of TCP connections. E.g., there can now be one TCP connection for the > "DESCRIBE"; another TCP connection for each "SETUP"; another TCP > connection for "PLAY", etc. (Of course, this applies only to RTP/UDP > sessions; RTP/TCP sessions have to use the same TCP connection, from > "SETUP" through "TEARDOWN".) > > > Similarly, a single TCP connection can now be used for more than one > session (for the same client, of course). (Despite this, our own RTSP > *client* implementation continues to use a single TCP connection for > each session.) > > > The new RTSP server implementation does this by separating 'client > connection' from 'client session'. The "RTSPServer" class now has two > member classes: "RTSPServer::RTSPClientConnection" (for a single TCP > connection), and "RTSPServer::RTSPClientSession" (for a single client > session, possibly used by multiple TCP connections). You can, if you > wish, subclass these two classes, along with subclassing "RTSPServer" > itself. > > > I have also improved the way that the "RTSPServer" class manages > "ServerMediaSession" objects. (Recall that a "ServerMediaSession" > describes a single media stream source (possibly with 'subsessions' > for audio, video, etc.), regardless of how many clients happen to be > currently receiving it.) > - As before, the "RTSPServer::removeServerMediaSession()" function > removes a "ServerMediaSession" object from the server, thereby making > it inaccessible to new clients, but does not stop any ongoing > streaming to existing clients. > - A new function "RTSPServer::deleteServerMediaSession()" removes (and > deletes) a "ServerMediaSession" object from the server, *and also* > stops any streaming to existing clients. > - A new function > "RTSPServer::closeAllClientSessionsForServerMediaSession()" stops any > streaming (for a specified "ServerMediaSession" object) to existing > clients, but leaves the "ServerMediaSession" object on the server, so > that new clients can still access it. > - The "RTSPServer" destructor now removes and deletes all > "RTSPClientConnection" and "RTSPClientSession" objects, and thereby > also stops any existing ongoing streams. So, if you wish, you can > call "Medium::close()" on your "RTSPServer" object, knowing that this > will automatically stop all existing streaming, and reclaim all of its > objects. > > > Because these changes are substantial, and possibly have introduced > some bugs, I have done something unusual, by making the new source > code release an 'experimental' release. It's available at: > http://www.live555.com/liveMedia/public/live555-experimental.tgz > > > Eventually, however (possibly just within a week or so), this new > release will no longer be experimental; it will become the lone > supported "LIVE555 Streaming Media" release. > > > Therefore, if you're a developer who uses a RTSP server in your > application, you are encouraged to download and test the new > experimental release, and report back on any problems that you might > find. Note, in particular, that if you have subclassed "RTSPServer", > then you should download and test the new experimental version sooner > rather than later, because the API for subclassing has changed (the > API for creating new "RTSPClientSession"s has changed, and there's now > a new "RTSPClientConnection" class as well). > > > 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 Fri Jul 27 05:51:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jul 2012 05:51:38 -0700 Subject: [Live-devel] Updated RTSP server implementation to support multiple TCP connections per session - new experimental release In-Reply-To: <1343388361.3000.27.camel@localhost.localdomain> References: <575A2784-A62B-4960-B762-100188C7DA6A@live555.com> <1343388361.3000.27.camel@localhost.localdomain> Message-ID: > I am however facing some inheritance/relationship issues that I will try > to explain. > > I have subclassed RTSPServerSupportingHTTPStreaming, > RTSPServer::RTSPClientSession and RTSPServer::RTSPClientConnection > classes for my needs, overriding virtual methods. > > I am trying, in the SETUP phase for example, to augment the response > buffer with specific headers. In your case, you probably only need to subclass "RTSPServerSupportingHTTPStreaming"[*] and "RTSPServer::RTSPClientConnection", but *not* "RTSPServer::RTSPClientSession", because the response buffer is managed by the "RTSPServer::RTSPClientConnection" class only. Of course, you will also need to redefine the virtual function "createNewClientConnection()" (but *not* createNewClientSession()") Because you already - with the old version of the code - were able to successfully subclass "RTSPServer::RTSPClientSession", you should be able to do the same with the new version of the code - but subclassing "RTSPServer::RTSPClientConnection" instead. Ross Finlayson Live Networks, Inc. http://www.live555.com/ [*] Note that you need the "RTSPServerSupportingHTTPStreaming" class only if you plan to support Apple's "HTTP Live Streaming" protocol (of indexed Transport Stream files only) to iPhones/iPads. If you don't need this, and just want to do RTSP, then you need only subclass "RTSPServer". -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 27 06:04:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jul 2012 06:04:20 -0700 Subject: [Live-devel] Updated RTSP server implementation to support multiple TCP connections per session - new experimental release In-Reply-To: <1343388361.3000.27.camel@localhost.localdomain> References: <575A2784-A62B-4960-B762-100188C7DA6A@live555.com> <1343388361.3000.27.camel@localhost.localdomain> Message-ID: <90B0919F-705B-4D3E-814E-3A3162A0E5DF@live555.com> Oops, my mistake: I just took another look at your message, and realized that - because you want to modify the response buffer while handling a "SETUP" command - you probably do, indeed, need to subclass "RTSPServer::RTSPClientSession" as well (because "handleCmd_SETUP()" is a member function of "RTSPServer::RTSPClientSession"). But you can probably solve your 'protected fResponseBuffer' problem quite easily, by defining - in your "RTSPServer::RTSPClientConnection" subclass - a function: unsigned char* responseBuffer() { return fResponseBuffer; } And then - in your "RTSPServer::RTSPClientSession" subclass - doing a "strstr()" to "ourClientConnection->responseBuffer()", rather than to "conn->fResponseBuffer". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.orry at em-sys.fr Fri Jul 27 06:36:16 2012 From: lionel.orry at em-sys.fr (Lionel Orry) Date: Fri, 27 Jul 2012 15:36:16 +0200 Subject: [Live-devel] Updated RTSP server implementation to support multiple TCP connections per session - new experimental release In-Reply-To: <90B0919F-705B-4D3E-814E-3A3162A0E5DF@live555.com> References: <575A2784-A62B-4960-B762-100188C7DA6A@live555.com> <1343388361.3000.27.camel@localhost.localdomain> <90B0919F-705B-4D3E-814E-3A3162A0E5DF@live555.com> Message-ID: <1343396176.3000.45.camel@localhost.localdomain> Hi Ross, thank you for your replies. My comment below. Regards, Lionel On Fri, 2012-07-27 at 06:04 -0700, Ross Finlayson wrote: > Oops, my mistake: > > > I just took another look at your message, and realized that - because > you want to modify the response buffer while handling a "SETUP" > command - you probably do, indeed, need to subclass > "RTSPServer::RTSPClientSession" as well (because "handleCmd_SETUP()" > is a member function of "RTSPServer::RTSPClientSession"). > Yes that's what I was about to answer. :) > > But you can probably solve your 'protected fResponseBuffer' problem > quite easily, by defining - in your "RTSPServer::RTSPClientConnection" > subclass - a function: > unsigned char* responseBuffer() { return fResponseBuffer; } > Not at all, the problem is the other way around. I'll try to give more details. If you check my code outlines again, you will notice that 'ourClientConnection' is of type RTSPServer::RTSPClientConnection (see prototype of SETUP handler method). Any method called against ourClientConnection is resolved on RTSPServer::RTSPClientConnection, thus the responseBuffer() method would not help. I tried, it throws: ?class RTSPServer::RTSPClientConnection? has no member named ?responseBuffer? You may also suggest me to consider why I need to subclass RTSPClientConnection, but the fact is I also need to override some of its handlers (i.e. out-of-session handlers) for OPTIONS, GET_PARAMETERS, for example. So I really need to subclass both RTSPClientSession and RTSPClientConnection. My first idea, to be honest, was to pass (MyOwnRTSPServer::RTSPClientConnection*) as the type of the handler first parameter, but when I do that it is not detected as an override of the original handler, because prototypes differ. The original implementation only was called. To keep things clean, maybe I should implement wrappers, like this: ------------------------------------------------------------- void MyOwnRTSPServer::RTSPClientSession::handleCmd_SETUP( RTSPServer::RTSPClientConnection* ourClientConnection, char const* urlPreSuffix, char const* urlSuffix, char const* fullRequestStr) { // dynamic_cast to get our own subclass type, // then call our implementation RTSPClientConnection* conn = dynamic_cast( ourClientConnection); handleMyCmd_SETUP(conn, urlPreSuffix, urlSuffix, fullRequestStr); } void MyOwnRTSPServer::RTSPClientSession::handleMyCmd_SETUP( RTSPClientConnection* conn, char const* urlPreSuffix, char const* urlSuffix, char const* fullRequestStr) { // specific stuff with my instance // call original implementation RTSPServer::RTSPClientSession::handleCmd_SETUP(conn, urlPreSuffix, urlSuffix, fullRequestStr); // Here, I can access conn->fResponseBuffer because // MyOwnRTSPServer::RTSPClientSession is a friend class of // MyOwnRTSPServer::RTSPClientConnection. } ------------------------------------------------------------- The ideal solution I think would be to make MyOwnRTSPServer::RTSPClientSession a friend call of RTSPServer::RTSPClientConnection but that means modifying the original headers, which I obviously don't want to do to keep away from license issues, and that would also mean make RTSPServer aware of my own class which is not desirable either. > > And then - in your "RTSPServer::RTSPClientSession" subclass - doing a > "strstr()" to "ourClientConnection->responseBuffer()", rather than to > "conn->fResponseBuffer". > > > 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 Fri Jul 27 06:52:39 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jul 2012 06:52:39 -0700 Subject: [Live-devel] Updated RTSP server implementation to support multiple TCP connections per session - new experimental release In-Reply-To: <1343396176.3000.45.camel@localhost.localdomain> References: <575A2784-A62B-4960-B762-100188C7DA6A@live555.com> <1343388361.3000.27.camel@localhost.localdomain> <90B0919F-705B-4D3E-814E-3A3162A0E5DF@live555.com> <1343396176.3000.45.camel@localhost.localdomain> Message-ID: <37C0C269-F131-47EB-A03A-28F98ADF9522@live555.com> Well, since you know - in your own code - that the "ourClientConnection" parameter to your "handleCmd_SETUP()" implementation will really be a "MyOwnRTSPServer::RTSPClientConnection*", I see no problem in you making that cast. There's no type safety issue here, because you know that the cast is true - i.e., you're not lying at all about the type of "ourClientConnection" in this case. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Fri Jul 27 13:08:51 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Fri, 27 Jul 2012 20:08:51 +0000 Subject: [Live-devel] Design choice Message-ID: When implementing liveMedia using multiple streams in one process I see two choices: 1. Each stream is kept totally separate. I.e. each stream have their own TaskScheduler, UsageEnvironment, eventLoopWatchVariable and each doEventLoop() is running in a separate thread. 2. The rtspClient's share the same TaskScheduler, UsageEnvironment, eventLoopWatchVariable and there is one doEventLoop() running (as in the testRTSPClient project). I've current implemented design 1, while I see option 2 being the intended choice. The reason for picking 1 is the added "security" of keeping each stream entirely independent, i.e. if an exception occurs for any reason only one stream should be affected. As I'm fairly new to the liveMedia library I however wanted to see if anyone has an opinion on this. The overhead doesn't appear to be an issue even with 10+ streams. Could there be any possible drawbacks with option 1 that I have overseen? /Claes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Fri Jul 27 13:23:42 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jul 2012 13:23:42 -0700 Subject: [Live-devel] Design choice In-Reply-To: References: Message-ID: > When implementing liveMedia using multiple streams in one process I see two > choices: > > 1. Each stream is kept totally separate. I.e. each stream have their own > TaskScheduler, UsageEnvironment, eventLoopWatchVariable and each > doEventLoop() is running in a separate thread. > > 2. The rtspClient's share the same TaskScheduler, UsageEnvironment, > eventLoopWatchVariable and there is one doEventLoop() running (as in the > testRTSPClient project). Correct. Those are the only two choices, *if* you have also chosen to use just one process. (Note below.) > I've current implemented design 1, while I see option 2 being the intended > choice. The reason for picking 1 is the added "security" of keeping each > stream entirely independent, i.e. if an exception occurs for any reason only > one stream should be affected. Well, it depends on what you mean by "exception". If one thread has a memory access error, then it will kill the entire process. And there's nothing to prevent one thread (due to a bug somewhere) from stepping all over memory that's used by another thread. So there's really not much 'security' here at all. If your streams really are "entirely independent", then why not use one process for each stream? That is by far the safest and most reliable approach. But for some odd reason, here in the 21st century, the idea of structuring an application as multiple processes seems to have fallen our of favor... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Fri Jul 27 14:57:50 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 27 Jul 2012 15:57:50 -0600 Subject: [Live-devel] Network congestion while using Live555 framework (resending with proper formatting) In-Reply-To: References: Message-ID: <50130EDE.9000308@etr-usa.com> On 7/27/2012 12:20 AM, Saurabh Gandhi wrote: > > The system worked fine for over two days You aren't using an old version of Live555 are you? They fixed an integer overflow bug 8 months ago to let MPEG2TransportStreamFramer manage a stream for more than a few days. > after two days we experienced a network congestion. That's not what your screenshot shows. I guess you're using that term colloquially, because you certainly aren't using it in its correct technical way: http://en.wikipedia.org/wiki/Network_congestion The highlighted packet in your screenshot has hundreds of milliseconds of space around it. The only way that's "congestion" is if we're talking about a 300 bps modem link. In any case, unanswered ARPs are *way* below the level of Live555. Live555 cannot break your network stack's ability to answer ARP. Live555 *could* send enough traffic to a broken switch that it falls over, but that's not really a Live555 problem, it's a broken switch. Does rebooting the switch(es) between these endpoints fix it? > what was happening using wire-shark (refer attachment). In future, it would be better if you send a .pcap file instead. It contains more useful information, it can be manipulated, and as long as you prefilter the packets for us, it'll probably be smaller, too. You can safely assume that everyone on this list either has Wireshark handy, or can get it. :) From kl222 at 126.com Fri Jul 27 03:24:57 2012 From: kl222 at 126.com (kl222) Date: Fri, 27 Jul 2012 18:24:57 +0800 Subject: [Live-devel] Recommends using CMAke management live555 project Message-ID: <000701cd6be2$1235a960$36a0fc20$@126.com> Cmake is the cross-platform, open-source build system. CMake is a family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. http://www.cmake.org/ Was I in the attachment based on July 26, 2012 live version adds the CMake files. It already supports UNIX,linux and Windows systems. Usage: On the unix or linux: #cmake . #build Makefile #make On the windows: 1. Open the cmake gui : 2. Fill in the root of live project to the textbox of Where is the source code. 3. Fill in the build path to the textbox of where to build the binaries. 4. push configue button in order to configue cmake . 5. push generate button in order to generate vs project files. 6. using vs open live555.sln in the build path. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: live.2012.07.27.rar Type: application/octet-stream Size: 889325 bytes Desc: not available URL: From saurabhg84 at gmail.com Fri Jul 27 07:05:19 2012 From: saurabhg84 at gmail.com (saurabhg84 at gmail.com) Date: Fri, 27 Jul 2012 14:05:19 +0000 Subject: [Live-devel] Network congestion while using Live555 framework (resending with proper formatting) In-Reply-To: References: Message-ID: <999702742-1343397921-cardhu_decombobulator_blackberry.rim.net-1082220651-@b27.c18.bise7.blackberry> Hello Ross, We do have a domain name. Unfortunately, all mails from this mailing list get marked as spam by default due to some mail server policy that we have adopted. I do understand that its frustrating to reply when the problem is not correctly described or is too vague. However, to the best of my knowledge this is an apt description of the problem based on the data which is available with us. In case I can help by providing some more details kindly let me know. As such we are pretty sure that these congestion issues won't arise out of live555 if so many ppl are already using it within their products. Having said this, do help us out if you can. Thanks a lot for your responses. Sent on my BlackBerry? from Vodafone -----Original Message----- From: Ross Finlayson Sender: live-devel-bounces at ns.live555.comDate: Fri, 27 Jul 2012 02:14:03 To: LIVE555 Streaming Media - development & use Reply-To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Network congestion while using Live555 framework (resending with proper formatting) _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From warren at etr-usa.com Fri Jul 27 15:34:51 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 27 Jul 2012 16:34:51 -0600 Subject: [Live-devel] Recommends using CMAke management live555 project In-Reply-To: <000701cd6be2$1235a960$36a0fc20$@126.com> References: <000701cd6be2$1235a960$36a0fc20$@126.com> Message-ID: <5013178B.4000000@etr-usa.com> On 7/27/2012 4:24 AM, kl222 wrote: > CMake is used to > control the software compilation process using simple platform and > compiler independent configuration files. CMake generates native > makefiles and workspaces that can be used in the compiler environment of > your choice. It probably fixes the trailing space problem with BSD make, too. I was going to suggest cmake as an option for fixing this, but thought I'd better provide the cmakefiles for it at the same time to avoid the Someone Has To Do It counterargument. Now someone has. :) From tim at rabbit.tv Fri Jul 27 15:22:11 2012 From: tim at rabbit.tv (Tim Zaitsev) Date: Fri, 27 Jul 2012 15:22:11 -0700 Subject: [Live-devel] Design choice In-Reply-To: References: Message-ID: Ross, This is fascinating but I can't picture it. What would the design look like for multiple processes (one per stream as you describe)? Are there any examples of this that I can take a look at? Thanks, Tim On Fri, Jul 27, 2012 at 1:23 PM, Ross Finlayson wrote: > When implementing liveMedia using multiple streams in one process I see two > choices: > > 1. Each stream is kept totally separate. I.e. each stream have their own > TaskScheduler, UsageEnvironment, eventLoopWatchVariable and each > doEventLoop() is running in a separate thread. > > 2. The rtspClient's share the same TaskScheduler, UsageEnvironment, > eventLoopWatchVariable and there is one doEventLoop() running (as in the > testRTSPClient project). > > > Correct. Those are the only two choices, *if* you have also chosen to use > just one process. (Note below.) > > > I've current implemented design 1, while I see option 2 being the intended > choice. The reason for picking 1 is the added "security" of keeping each > stream entirely independent, i.e. if an exception occurs for any reason > only > one stream should be affected. > > > Well, it depends on what you mean by "exception". If one thread has a > memory access error, then it will kill the entire process. And there's > nothing to prevent one thread (due to a bug somewhere) from stepping all > over memory that's used by another thread. So there's really not much > 'security' here at all. > > If your streams really are "entirely independent", then why not use one > process for each stream? That is by far the safest and most reliable > approach. > > But for some odd reason, here in the 21st century, the idea of structuring > an application as multiple processes seems to have fallen our of favor... > > 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 Jul 27 16:07:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jul 2012 16:07:54 -0700 Subject: [Live-devel] Design choice In-Reply-To: References: Message-ID: > This is fascinating but I can't picture it. What would the design look like for multiple processes (one per stream as you describe)? > > Are there any examples of this that I can take a look at? Sure. For a (very) simple example, imagine a shell script like the following: #! /bin/sh openRTSP -F stream1_ rtsp://stream1.example.com & openRTSP -F stream2_ rtsp://stream2.example.com & openRTSP -F stream3_ rtsp://stream3.example.com & I.e., have one process (in this case, a shell running a script, although it could also be a compiled application) that spawns ('exec's) multiple concurrent processes ('sub-applications') - one for each desired stream that you want to receive. People have been structuring applications like this for decades. I'm puzzled by why so many programmers these days seem afraid (or unaware) to do this. (I suspect, however, that it might be due to the fact that so many programmers these days have grown up using nothing but graphical IDEs (integrated development environments), which only generate applications in which everything runs in one process.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Fri Jul 27 16:22:55 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 27 Jul 2012 17:22:55 -0600 Subject: [Live-devel] Design choice In-Reply-To: References: Message-ID: <501322CF.4070002@etr-usa.com> On 7/27/2012 5:07 PM, Ross Finlayson wrote: > > I'm > puzzled by why so many programmers these days seem afraid (or unaware) > to do this. I think it's a legacy of 1990s Windows and Mac OS: poor IPC, poor process management, etc. But they had threads, which avoids the need for either. Now we've got a generation of programmers who didn't face the opposite problem: bad or missing thread implementations, but excellent IPC and process management, which encourages cooperative multi-process agglomerations. Tim, I recommend you read any book by W. Richard Stevens, and this: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf tl;dr on the latter: threads are mathematically proven to be evil. From Jeremiah.Morrill at econnect.tv Fri Jul 27 16:53:10 2012 From: Jeremiah.Morrill at econnect.tv (Jeremiah Morrill) Date: Fri, 27 Jul 2012 23:53:10 +0000 Subject: [Live-devel] Design choice In-Reply-To: <501322CF.4070002@etr-usa.com> References: , <501322CF.4070002@etr-usa.com> Message-ID: <7D7BA7A2-161A-4CB4-B0F8-1BB7B009AF43@econnect.tv> I went with a 1 thread per rtsp client and regret it from a scaling perspective. The stack mem needed plus the overhead of having a thread gets to be too much when you get into a large amounts of streams. The library is _very_ well written to be non blocking and given the speed of your slowest server CPU, you won't see any bottle necks with a single CPU. If I could do it all over again I'd code it to use n-clients per thread. Just NEVER write any blocking code on that thread. If you do need to delay a long running operation, simply re-enter the live555 message loop and set the watch var when done. Sent from my iPhone On Jul 27, 2012, at 4:27 PM, "Warren Young" wrote: > On 7/27/2012 5:07 PM, Ross Finlayson wrote: >> >> I'm >> puzzled by why so many programmers these days seem afraid (or unaware) >> to do this. > > I think it's a legacy of 1990s Windows and Mac OS: poor IPC, poor process management, etc. But they had threads, which avoids the need for either. > > Now we've got a generation of programmers who didn't face the opposite problem: bad or missing thread implementations, but excellent IPC and process management, which encourages cooperative multi-process agglomerations. > > Tim, I recommend you read any book by W. Richard Stevens, and this: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > tl;dr on the latter: threads are mathematically proven to be evil. > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From finlayson at live555.com Fri Jul 27 22:11:37 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jul 2012 22:11:37 -0700 Subject: [Live-devel] Recommends using CMAke management live555 project In-Reply-To: <000701cd6be2$1235a960$36a0fc20$@126.com> References: <000701cd6be2$1235a960$36a0fc20$@126.com> Message-ID: <9B9DA945-FFE9-4BC8-948C-A62CC37335E3@live555.com> The suggestion of replacing the "genMakefiles"/"genWIndowsMakefiles" configuration tools with "cmake" comes up every few years. The last time someone suggested it was in June 2010; here is my response from back then: http://lists.live555.com/pipermail/live-devel/2010-June/012244.html Unfortunately the results of the poll that I called for then were underwhelming, to say the least. I got 8 responses. 2 people said that they wanted the configuration tools left as is. 3 people said that they would prefer switching to "cmake". The other 3 people said that they didn't care either way. So, with such an anemic response, I concluded that there was simply no consensus for making such a change. The fact that more than 2 years elapsed until anyone proposed this again reinforces this conclusion. But there's a more practical objection to using "cmake": It - at least with the configuration file that was provided - doesn't work for all platforms/development environments that we support. I tried it yesterday, and found: - It works on Mac OS X (except that it got the names of the target application binaries (e.g., "live555MediaServer") wrong; however, I assume that that is something that could easily be fixed). - It doesn't work on FreeBSD, because to successfully compile the code on FreeBSD, the flag "-DXLOCALE_NOT_USED=1" needs to be added to the command line. Similarly, for various other platforms, other (platform-specific) flags need to be added. For the existing tools, the "config." files serve this purpose. For "cmake", presumably some similar platform-specific configuration stuff would need to be added - which would defeat the supposed simplicity benefit of using "cmake". - For Windows, it doesn't seem to support certain old versions of Microsoft 'Visual Studio' - e.g., version 5.0 (which is what I happen to use for testing LIVE555 builds for Windows). So based on all this: Although anyone is (of course) welcome to use "cmake" or any other tools themselves. However, at least for now, I won't be supporting it in our released code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhg84 at gmail.com Sat Jul 28 04:48:51 2012 From: saurabhg84 at gmail.com (Saurabh Gandhi) Date: Sat, 28 Jul 2012 17:18:51 +0530 Subject: [Live-devel] Network congestion while using Live555 framework (resending with proper formatting) In-Reply-To: <50130EDE.9000308@etr-usa.com> References: <50130EDE.9000308@etr-usa.com> Message-ID: Kindly find my replies inline in blue: On Sat, Jul 28, 2012 at 3:27 AM, Warren Young wrote: > On 7/27/2012 12:20 AM, Saurabh Gandhi wrote: > >> >> The system worked fine for over two days >> > > You aren't using an old version of Live555 are you? They fixed an integer > overflow bug 8 months ago to let MPEG2TransportStreamFramer manage a stream > for more than a few days. We are using the latest version built from Live555 source available here: http://www.live555.com/liveMedia/public/ after two days we experienced a network congestion. > That's not what your screenshot shows. > > I guess you're using that term colloquially, because you certainly aren't > using it in its correct technical way: > > http://en.wikipedia.org/wiki/**Network_congestion > > The highlighted packet in your screenshot has hundreds of milliseconds of > space around it. The only way that's "congestion" is if we're talking > about a 300 bps modem link. > Okay, got it. Sorry for creating the confusion. > > In any case, unanswered ARPs are *way* below the level of Live555. Live555 > cannot break your network stack's ability to answer ARP. Live555 *could* > send enough traffic to a broken switch that it falls over, but that's not > really a Live555 problem, it's a broken switch. > > Does rebooting the switch(es) between these endpoints fix it? This speculation seems to be making sense. Yes, the rebooting of switches between these endpoints does solve the issue. > > > what was happening using wire-shark (refer attachment). >> > > In future, it would be better if you send a .pcap file instead. It > contains more useful information, it can be manipulated, and as long as you > prefilter the packets for us, it'll probably be smaller, too. > > You can safely assume that everyone on this list either has Wireshark > handy, or can get it. :) Thanks a lot for your response. Let me reproduce the problem and get hold of a .pcap as suggested by you. Thanks once again for your response. > > ______________________________**_________________ > 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: