From matteo.lisi at engicam.com Mon Sep 3 07:29:12 2012 From: matteo.lisi at engicam.com (Matteo Lisi) Date: Mon, 03 Sep 2012 16:29:12 +0200 Subject: [Live-devel] Question about QuictTimeFilesync Message-ID: <5044BEB8.2080805@engicam.com> Hi to all... I'm trying to modify the openRTSP. I need to save the the rtsp stream into files with one minute length. For do this I need modify the QuickTimeFileSink class, adding the changeoutputfile method that I have to call each minute... Have you some ideas about how I can do this ? Many thanks From fraph at free.fr Sun Sep 2 10:48:01 2012 From: fraph at free.fr (Raph) Date: Sun, 02 Sep 2012 19:48:01 +0200 Subject: [Live-devel] How is the best way to realize it ? Message-ID: As someone knows, I asked to Ross Finlayson to integrate one more kind of stream in the sources. the specification of this stream is to be able to play aver RTSP an 48khz 24bits wav audio files. And now this works very well. But I would like to do something else with this kind of stream, and I would like to know what is the best way to realize it. I'm explainng : I'm doing live mix of my recorded session, so from I own an Nuendo software that allows me to mix several tracks (until 108 tracks sometimes) with eq, fx, and so on. With nuendo I use an plugin that sends my Master Mix (Strereo 48khz / 24 bits) to my dedicated server. The way of the plugin sends audio datas to my server use UDP RAW packet on a specified port (65010). I made a program that get these audio datas, convert them in a good format (there an convertion from 32bits floats to 24b unsigned) and write them to an Named Pipe which names /tmp/my_pipe On that pipe there is only the samples of the audio, there is nothing else. Now, I would like to stream these datas with an modified version of testOnDemandRTSPServer. I try very simply to modify the name of 'test.wav' by '/tmp/my_fifo'. But it doesn't work. As I supposed... So, what is the most efficient way to do it. I just want the testOnDemandRTSPServer reading the samples from an Named pipe and sending this stream over the net. It's like realtime streaming (i don't use an fixed sized file). So from if I modify an eq, an fx or just change my mix, then the people who is earing it will ear my modifications at the same time, so from we can discuss about the mix. Thanks a lot if you have some idea to do this. Grag38 ps : A short schema of the process : Home with Nuendo + plugin ---> UDP PACKET int Float32bits port 65010 --> dedicated server --> Conversion programme : Get UDP PACKET - EXTRACT AUDIO DATAS - Convert them to 24bits - write theme pipe /tmp/my_fifo I need : testOnDemandRTSPServer to get datas from /tmp/my_fifo (datas are in the same order than a WAV 24b LE wav file) and stream it. -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From owen at metamachine.com Tue Sep 4 08:35:32 2012 From: owen at metamachine.com (owen at metamachine.com) Date: Tue, 4 Sep 2012 08:35:32 -0700 Subject: [Live-devel] Possible bug report, and a question Message-ID: <01328f0478cdc1cf68e4f6058a74777a.squirrel@www.metamachine.com> I've found a possible 'bug' that might just be an extra variable decl, but might be a cut'n'paste bug. In liveMedia/MP3Internals.cpp, in the member function MP3FrameParams::getSideInfo(MP3SideInfo&), there's a var declared named i_stereo. It gets initialized, but never used. It looks like it might want to be used in the subsequent call to getSideInfo1() instead of passing in ms_stereo, but I don't know the code base well enough yet. ---- I'm auditing the code for possible inclusion in a moderately sized but high-traffic civil application (Toll road monitoring which includes h.264 cameras). I'm getting up-to-speed on the framework slowly. The code is very approachable: well-chosen abstractions and the framework seems made for extending by deriving existing classes that only make appropriate members virtual. Is someone writing an O'Reilly book on this yet? // Wally Wallace Owen Kapsch TrafficCom From owen at metamachine.com Tue Sep 4 08:37:14 2012 From: owen at metamachine.com (owen at metamachine.com) Date: Tue, 4 Sep 2012 08:37:14 -0700 Subject: [Live-devel] Possible bug Message-ID: <076c3ce014bcdc227a06d8df2e025294.squirrel@www.metamachine.com> In liveMedia/RTSPServer.cpp, on line 1252, there's a multi clause if statement that, as formatted, looks like you want it to be evaluated in a way that precedence rules say you will get a surprise. The line looks like this: if (streamingMode == RTP_TCP && rtpChannelId == 0xFF || streamingMode != RTP_TCP && ourClientConnection->fClientOutputSocket != ourClientConnection->fClientInputSocket) {...} It looks like you expect it to be evaluated like this: if ((streamingMode == RTP_TCP && rtpChannelId == 0xFF || streamingMode != RTP_TCP) && (ourClientConnection->fClientOutputSocket != ourClientConnection->fClientInputSocket)) {...} The compiler will actually give you this: if ((streamingMode == RTP_TCP && rtpChannelId == 0xFF) || (streamingMode != RTP_TCP && ourClientConnection->fClientOutputSocket != ourClientConnection->fClientInputSocket)) {...} because && has slightly higher precedence than ||. // Wally, hopefully not wasting your time. From finlayson at live555.com Tue Sep 4 09:52:32 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Sep 2012 09:52:32 -0700 Subject: [Live-devel] How is the best way to realize it ? In-Reply-To: References: Message-ID: <1FD2E02B-38F6-441F-814A-FA4EABEE6F2D@live555.com> > I try very simply to modify the name of 'test.wav' by '/tmp/my_fifo'. But it doesn't work. No, you can't do that, because the "WAVAudioFileSource" class is intended for reading from a WAV file (with a WAV header at the front). > So, what is the most efficient way to do it. I just want the testOnDemandRTSPServer reading the samples from an Named pipe and sending this stream over the net. See You will need to define and implement your own subclass of "OnDemandServerMediaSubsession", and, in particular, reimplement the "createNewStreamSource()" and "createNewRTPSink()" virtual functions. For tips on how to do this, see "WAVAudioFileServerMediaSubsession.cpp" Because you are streaming 24-bit stereo PCM audio, read from a pipe, your "createNewStreamSource()" function should: - Create a "ByteStreamFileSource", with "preferredFrameSize" being some multiple of 6 bytes (one 24-bit stereo PCM sample), with "playTimePerFrame" set appropriately (microseconds). Choose a "preferredFrameSize" that's large enough to fit within an outgoing RTP packet. I suggest 1500 bytes (i.e., 250 samples), with "playTimePerFrame" of 5208 microseconds (assuming a sampling rate of 48 kHz). - You must then feed this into a "EndianSwap24" object (see line 118 of "WAVAudioFileServerMediaSubsession.cpp") Your "createNewRTPSink()" function can be very simple. You just call: return SimpleRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic, 48000, "audio", "L24", 2); (again, assuming a 48 kHz sampling rate) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 4 09:53:16 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Sep 2012 09:53:16 -0700 Subject: [Live-devel] Possible bug report, and a question In-Reply-To: <01328f0478cdc1cf68e4f6058a74777a.squirrel@www.metamachine.com> References: <01328f0478cdc1cf68e4f6058a74777a.squirrel@www.metamachine.com> Message-ID: <93BFCDD6-F36B-4210-A54C-3A7127594B04@live555.com> > In liveMedia/MP3Internals.cpp, in the member function > MP3FrameParams::getSideInfo(MP3SideInfo&), there's a var declared named > i_stereo. > > It gets initialized, but never used. Yes, that variable doesn't need to be there. Thanks. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 4 09:56:53 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Sep 2012 09:56:53 -0700 Subject: [Live-devel] Possible bug In-Reply-To: <076c3ce014bcdc227a06d8df2e025294.squirrel@www.metamachine.com> References: <076c3ce014bcdc227a06d8df2e025294.squirrel@www.metamachine.com> Message-ID: > In liveMedia/RTSPServer.cpp, on line 1252, there's a multi clause if > statement that, as formatted, looks like you want it to be evaluated in a > way that precedence rules say you will get a surprise. > > The line looks like this: > if (streamingMode == RTP_TCP && rtpChannelId == 0xFF || > streamingMode != RTP_TCP && ourClientConnection->fClientOutputSocket > != ourClientConnection->fClientInputSocket) {...} > > It looks like you expect it to be evaluated like this: > if ((streamingMode == RTP_TCP && rtpChannelId == 0xFF || streamingMode != > RTP_TCP) && (ourClientConnection->fClientOutputSocket != > ourClientConnection->fClientInputSocket)) {...} > > The compiler will actually give you this: > if ((streamingMode == RTP_TCP && rtpChannelId == 0xFF) || (streamingMode > != RTP_TCP && ourClientConnection->fClientOutputSocket != > ourClientConnection->fClientInputSocket)) {...} > > because && has slightly higher precedence than ||. This (the latter interpretation) is actually what I wanted - so the code is not in error. However, I'll add parentheses to the code, to make the meaning clearer. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 4 10:21:34 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Sep 2012 10:21:34 -0700 Subject: [Live-devel] How is the best way to realize it ? In-Reply-To: <1FD2E02B-38F6-441F-814A-FA4EABEE6F2D@live555.com> References: <1FD2E02B-38F6-441F-814A-FA4EABEE6F2D@live555.com> Message-ID: <0D116BE8-3032-4496-B5EC-2F2628930897@live555.com> > Choose a "preferredFrameSize" that's large enough to fit within an outgoing RTP packet. I suggest 1500 bytes (i.e., 250 samples), with "playTimePerFrame" of 5208 microseconds (assuming a sampling rate of 48 kHz). I made a mistake there. 1500 bytes is a bit too large to fit within a packet (assuming the code's current packet size settings). Instead, I suggest 1440 bytes (== 240 samples), with a "playTimePerFrame" of 5000 microseconds (assuming a sampling rate of 48 kHz). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinkuokingking at hotmail.com Mon Sep 3 09:38:02 2012 From: kevinkuokingking at hotmail.com (kingking kuo) Date: Mon, 3 Sep 2012 16:38:02 +0000 Subject: [Live-devel] help! When I use openRTSP to visitor remote RTSP Server Message-ID: I use the test program openRTSP to visitor remote RTSP server, after openRTSP send command "PLAY", the RTSP server return many RTP packet, but openRTSP process can't process those packet, and openRTSP's cpu usage 50%. please help me! command Line: openRTSP.exe -t rtsp://svn.119bk.com:554/0/888888:888888/main note: I used "VLC" player, that can play well. thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 4 23:00:39 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Sep 2012 23:00:39 -0700 Subject: [Live-devel] help! When I use openRTSP to visitor remote RTSP Server In-Reply-To: References: Message-ID: > I use the test program openRTSP to visitor remote RTSP server, after openRTSP send command "PLAY", the RTSP server return many RTP packet, but openRTSP process can't process those packet, and openRTSP's cpu usage 50%. please help me! You realize, I hope, that "openRTSP" doesn't decode or 'play' the stream. It merely receives the audio and video streams, and writes the data to files. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvyagintsev at atlantis.ru Tue Sep 4 23:52:15 2012 From: zvyagintsev at atlantis.ru (=?koi8-r?B?+tfRx8nOw8XXIOHO1M/O?=) Date: Wed, 5 Sep 2012 10:52:15 +0400 Subject: [Live-devel] windows, live555, tcp transport Message-ID: <000301cd8b32$fbf9f320$f3edd960$@ru> Hello. I am working on rtsp client software. Everything works fine until the transport on the server side was changed to tcp. I got the 461 error in "after-setup" handler. Ok, this is the easiest part - I just make some modification to code and handle this case (another try to setup session is done with the call to sendSetupCommand() and streamUsingTcp set to "true", hope this is enough?). No errors but also no incoming data in MediaSink object - my client just stuck in loop without any notification of data. I tried to use openrtsp: openRTSP -n -t -b 262144 "rtsp://myurl" the last lines of output: Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Session: c2f Started playing session Receiving streamed data... Data packets have begun arriving [1346827501853] openRTSP create file for stream (h264) but it is empty no matter how much time i wait. In other way the latest VLC Player (afaik it uses live555) able to play rtsp://myurl without any problems. At first glance this looks like a problem with my build of live555 - I build live555 and openrtsp myself using ms vc 2010. Any ideas or suggestions how to fix this? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 5 01:15:50 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Sep 2012 01:15:50 -0700 Subject: [Live-devel] windows, live555, tcp transport In-Reply-To: <000301cd8b32$fbf9f320$f3edd960$@ru> References: <000301cd8b32$fbf9f320$f3edd960$@ru> Message-ID: > I am working on rtsp client software. Everything works fine until the transport on the server side was changed to tcp. I got the 461 error in ?after-setup? handler. Ok, this is the easiest part ? I just make some modification to code and handle this case (another try to setup session is done with the call to sendSetupCommand() and streamUsingTcp set to ?true?, hope this is enough?). I think you are misunderstanding what is happening here. When you (the client) request RTP-over-TCP streaming (by adding the "-t" option to "openRTSP"), the server decides whether or not it wants to support this. Because it returns a 461 error (meaning "Unsupported Transport"), this suggests that the server *does not* support RTP-over-TCP streaming. You cannot 'fix' this, and you should not modify the existing client code; the existing code is working OK. (Note also that if you modify the supplied code, you cannot expect any support on this mailing list.) Because this server apparently does not support RTP-over-TCP streaming, the "-t" option to "openRTSP" will not work, and you should not use it. (If you don't receive any data when you don't use "-t", then that probably means that you are behind a firewall that is blocking UDP packets. If so, you will need to fix (or remove) your firewall.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvyagintsev at atlantis.ru Wed Sep 5 01:33:14 2012 From: zvyagintsev at atlantis.ru (=?utf-8?b?0JfQstGP0LPQuNC90YbQtdCy?= =?utf-8?b?0JDQvdGC0L7QvQ==?=) Date: Wed, 5 Sep 2012 08:33:14 +0000 (UTC) Subject: [Live-devel] windows, live555, tcp transport References: <000301cd8b32$fbf9f320$f3edd960$@ru> Message-ID: Ross Finlayson writes: > > > > I am working on rtsp client software. Everything works fine until the transport on the server side was changed to tcp. I got the 461 error in ?after-setup? handler. Ok, this is the easiest part ? I just make some modification to code and handle this case (another try to setup session is done with the call to sendSetupCommand() and streamUsingTcp set to ?true?, hope this is enough?). > I think you are misunderstanding what is happening here. > > When you (the client) request RTP-over-TCP streaming (by adding the "-t" option to "openRTSP"), the server decides whether or not it wants to support this. ?Because it returns a 461 error (meaning "Unsupported Transport"), this suggests that the server *does not* support RTP-over-TCP streaming. ?You cannot 'fix' this, and you should not modify the existing client code; the existing code is working OK. ?(Note also that if you modify the supplied code, you cannot expect any support on this mailing list.) > > Because this server apparently does not support RTP-over-TCP streaming, the "-t" option to "openRTSP" will not work, and you should not use it. ?(If you don't receive any data when you don't use "-t", then that probably means that you are behind a firewall that is blocking UDP packets. ?If so, you will need to fix (or remove) your firewall.) > > Ross FinlaysonLive Networks, Inc.http://www.live555.com/ > I guess we missunderstood each other. I understand the difference between client and server side. Let me clarify things a little. My software (based on Live555) works pefectly with udp transport under the hood. Sure when i tried to use my client on the server with _only_ tcp transport available i get 461 error. I checked the samples source code and found the only change i need to do in my source code is to switch the streamUsingTcp flag to true in sendSetupCommand(). Ok, now my client connected, but i dont see any data coming. Live555 thread take 100% of cpu. Next i tried openrtsp with -t on same server (again - it support tcp transport) and got same result - no incoming data and no errors with cpu load high. But vlc player work perfectly on that rtsp source. From zvyagintsev at atlantis.ru Wed Sep 5 06:10:33 2012 From: zvyagintsev at atlantis.ru (=?utf-8?b?0JfQstGP0LPQuNC90YbQtdCy?= =?utf-8?b?0JDQvdGC0L7QvQ==?=) Date: Wed, 5 Sep 2012 13:10:33 +0000 (UTC) Subject: [Live-devel] windows, live555, tcp transport References: <000301cd8b32$fbf9f320$f3edd960$@ru> Message-ID: Ok, this looks like a problem with Live555 on windows compiled with ms vc (in my case its ms vc 2010). On linux openRTSP work fine. Included sample software (openRTSP) connects to server (with only tcp transport available), show no errors but still dont receive any data. Also OpenRTSP cpu usage is really high - 25% on my 4 core cpu. Ross, any chance you check and fix this behavior? I can provide windows binary executables or everything you need related to windows platform. From finlayson at live555.com Wed Sep 5 06:58:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Sep 2012 06:58:23 -0700 Subject: [Live-devel] windows, live555, tcp transport In-Reply-To: References: <000301cd8b32$fbf9f320$f3edd960$@ru> Message-ID: <6AE03018-3F19-4834-B719-A43F8E11CBBB@live555.com> > Ok, this looks like a problem with Live555 on windows compiled with ms vc (in my > case its ms vc 2010). On linux openRTSP work fine. > > Included sample software (openRTSP) connects to server (with only tcp transport > available), show no errors but still dont receive any data. Also OpenRTSP cpu > usage is really high - 25% on my 4 core cpu. > > Ross, any chance you check and fix this behavior? No, because I don't know what the problem is. Other people have not had problems getting "openRTSP" working correctly after compiling it for Windows. Because the problem seems to happen only for you, when you compile the code for Windows, you are going to have to figure out why this is. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevens at electricalscience.com Wed Sep 5 12:24:31 2012 From: stevens at electricalscience.com (Andy Stevens) Date: Wed, 05 Sep 2012 15:24:31 -0400 Subject: [Live-devel] simulate RTP packet loss Message-ID: <5047A6EF.8030404@electricalscience.com> Hi all, I would like to simulate packet loss of RTP packets on the network, and I would like to use Live555 to do this. In fact, there already is some code in MultiFramedRTPSink (in the MultiFramedRTPSink::sendPacketIfNecessary() function) which is contained in a "TEST_LOSS" macro, and is hardcoded to simulate 10% loss: #ifdef TEST_LOSS if ((our_random()%10) != 0) // simulate 10% packet loss ##### #endif I would like to do some more sophisticated testing (e.g. change the packet loss to 5% or 25%). What is the "right" way to do this? Ideally I would subclass MultiFramedRTPSink and then override the sendPacketIfNecessary() function. But sendPacketIfNecessary() is declared as "private" and so I cannot override. How best to simulate the packet loss without modifying the Live555 code directly? Regards, --Andy Stevens New York, USA From finlayson at live555.com Wed Sep 5 15:38:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Sep 2012 15:38:54 -0700 Subject: [Live-devel] simulate RTP packet loss In-Reply-To: <5047A6EF.8030404@electricalscience.com> References: <5047A6EF.8030404@electricalscience.com> Message-ID: <69C4955E-8231-45F3-B85F-5FCC56CDCFE1@live555.com> > I would like to simulate packet loss of RTP packets on the network, and I would like to use Live555 to do this. In fact, there already is some code in MultiFramedRTPSink (in the MultiFramedRTPSink::sendPacketIfNecessary() function) which is contained in a "TEST_LOSS" macro, and is hardcoded to simulate 10% loss: > > #ifdef TEST_LOSS > if ((our_random()%10) != 0) // simulate 10% packet loss ##### > #endif > > I would like to do some more sophisticated testing (e.g. change the packet loss to 5% or 25%). What is the "right" way to do this? Normally I don't advise modifying the supplied code. However, because you just want to simulate packet loss for testing (i.e., I presume you don't plan on building a product that loses packets :-), you might as well just modify the (#ifdef'd out) code that's already there. E.g., if you want to simulate N% packet loss (where N is an integer in the range [0,100], then you could change the "if" condition above to if ((our_random()%100 >= N) // simulate N% packet loss Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fraph at free.fr Tue Sep 4 14:18:46 2012 From: fraph at free.fr (Raph) Date: Tue, 04 Sep 2012 23:18:46 +0200 Subject: [Live-devel] How is the best way to realize it ? In-Reply-To: <0D116BE8-3032-4496-B5EC-2F2628930897@live555.com> References: <1FD2E02B-38F6-441F-814A-FA4EABEE6F2D@live555.com> <0D116BE8-3032-4496-B5EC-2F2628930897@live555.com> Message-ID: Thaks for this lot of informations. The things I realized are somewhere 'bad' way to realize it, but what I did is : Copy WAVAdioFileSource.cpp to ReaStreamAudio.cpp my own file Copy WAVAudioFileServerMediaSubsession.cpp to ReaStreamFileServerMediaSubsession.cpp with they corresponding .hh files. and recompile all of it. Based with the testOnRTSPServer.cpp sample code I could do some tests that worked. Things that are doing in a very bad way is just that I just remove some lines of code and delcare explicitely some variables like frequency, bytespersamples, etc... I really should have to use the object oriented implementation, but it needs some times to learn it at all. It's works ! But there is only one trouble to do it efficiently, which is : If I want to stream from home my own mix with 48k/24b I need at least 250k upload to do it in real time... So with my dsl connexion I've only 100k which is not enough... It's a problem of banddwidth about uploading datas. (fuck this limit). I wait to get an fiber or an VDSL connexion to realize it from home, and I will test all of these soft with an real optical fiber dsl connexion to chack it ! All of my tests, like simulate an udp stream that would come from my home directly on the server (cat rawWaveFile > /tmp/my_pipe) works very well to get back an RSTP stream of 48k/24b audio file. It's a real pleasure to discover Live555 open source code to test it on an real media server. It works very well. Best regards Grag38 ps : For people that are interested streaming live audio streaming : look at Reaper Software (http://www.reaper.fm and look at the ReaStram plugin that can stream until 8 tracks in real time audio without compression. But to do it, you really need a lot of bandwidth. If someone needs some explanations, he can mail me about it. >> Choose a "preferredFrameSize" that's large enough to fit within an >> outgoing RTP packet. I suggest 1500 bytes (i.e., 250 samples), with >> "playTimePerFrame" of 5208 microseconds (assuming a sampling rate of 48 >> kHz). > > I made a mistake there. 1500 bytes is a bit too large to fit within a > packet (assuming the code's current packet size settings). > > Instead, I suggest 1440 bytes (== 240 samples), with a > "playTimePerFrame" of 5000 microseconds (assuming a sampling rate of 48 > kHz). > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From Shaheed at scansoft.co.za Thu Sep 6 05:39:06 2012 From: Shaheed at scansoft.co.za (Shaheed Abdol) Date: Thu, 6 Sep 2012 14:39:06 +0200 Subject: [Live-devel] Access violation in StramParser::testBytes() Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8FDC@SSTSVR1.sst.local> Thank you Ross, I should at this point mention that I am using the DeviceSource template you provided as a means to retreive "live" footage from a DVR device. I am using the code on Windows, and am synchronizing access to the frame queue using critical sections. For this specific case, I am passing the data to live555 in chunks as large as possible - since it is not discrete data. This seems to work well in that I can avoid the cost of locking for each portion of data we need to dequeue. I was hoping you might be able to shed some light on why this works as well as it does, since the MPEG1or2Demux code seems to figuring out where the individual frames are within the data I pass to live555. For brevity I have included my derived createNewStreamSource function: [code] //Assume that info.isDiscrete = false, and m_codec = CODEC_ID_H264 for this case FramedSource * COnDemandVideoInputSubsession::createNewStreamSource(unsigned int clientSessionID, unsigned& estBitrate) { estBitrate = 500; //Not really hard coded, but not relevant to question InputDeviceSource * ids = InputDeviceSource::createNew(envir(), m_deviceParams); //assume that m_deviceParams contains pointer to frame queue switch (m_codec) { //checking if the stream is discrete, or elementary case CODEC_ID_H264: //we have no way of knowing if this is a discrete stream we are being fed (frame sizes seem pretty uniform to me though) { estBitrate = 1500; //higher bitrate for "high-def" streams (irrespective of the true throughput) if (info.isDiscrete) m_framedSource = H264VideoStreamDiscreteFramer::createNew(envir(), ids); else { MPEG1or2Demux * mpegDemux = MPEG1or2Demux::createNew(envir(), ids); MPEG1or2DemuxedElementaryStream * pesSource = mpegDemux->newVideoStream(); //same as using raw pes stream. m_framedSource = H264VideoStreamFramer::createNew(envir(), pesSource);//MPEG2TransportStreamFramer::createNew(envir(), ids);// } } break; case CODEC_ID_MPEG4: { if (info.isDiscrete) m_framedSource = MPEG4VideoStreamDiscreteFramer::createNew(envir(), ids); else m_framedSource = MPEG4VideoStreamFramer::createNew(envir(), ids); } break; } return m_framedSource; } [/code] The corresponding H264VideoRTPSink is created in the derived createNewRTPSink function. Could you think of a quicker method for me to acheive the same result? Thank you Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.meding at ids-imaging.de Thu Sep 6 05:04:52 2012 From: m.meding at ids-imaging.de (Meding, Matthias) Date: Thu, 6 Sep 2012 14:04:52 +0200 Subject: [Live-devel] Filestreaming Message-ID: <4CB3F3483954BD4ABD0B4DBB35C7E33802BB5B6E@exchsrv.idszentral.local> Hi Ross, maybe I have found a bug!?! In the method void RTSPServer::RTSPClientConnection::setRTSPResponse(char const* responseStr) { snprintf((char*)fResponseBuffer, sizeof fResponseBuffer, "RTSP/1.0 %s\r\n" "CSeq: %s\r\n" "%s\r\n" ---> should be "%s" "Session: %08X\r\n\r\n", responseStr, fCurrentCSeq, dateHeader(), sessionId); } Because the getLine-method in RTSPClient returns an blank line, and the following data (Session...) will be interpreted as "numExtraBytesAfterResponse" and will be saved in the "fResponseBuffer" --> next response will interpreted as a buggy one! Another question: On client-side I use the method "MediaSubsession::getNormalPlayTime". All works fine for the first play-command. But after the send of a second play-command the method returns wrong values with the receive of a new RTCP "SR" packet. Whats going wrong? Thanks in advance Matthias Meding -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 6 08:09:36 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Sep 2012 08:09:36 -0700 Subject: [Live-devel] Filestreaming In-Reply-To: <4CB3F3483954BD4ABD0B4DBB35C7E33802BB5B6E@exchsrv.idszentral.local> References: <4CB3F3483954BD4ABD0B4DBB35C7E33802BB5B6E@exchsrv.idszentral.local> Message-ID: <28D40585-2486-4CE0-AB00-B88A92C50CD1@live555.com> > maybe I have found a bug!?! > > In the method > > void RTSPServer::RTSPClientConnection::setRTSPResponse(char const* responseStr) > { > snprintf((char*)fResponseBuffer, sizeof fResponseBuffer, > "RTSP/1.0 %s\r\n" > "CSeq: %s\r\n" > "%s\r\n" ---> should be "%s" > "Session: %08X\r\n\r\n", > responseStr, > fCurrentCSeq, > dateHeader(), > sessionId); > } Yes, this is a bug - thanks. (Fortunately, it affected only responses to "PAUSE" commands (and some "GET_PARAMETER" and "SET_PARAMETER commands) - not the more common "DESCRIBE", "SETUP", or "PLAY" commands.) I have just installed a new version (2012.09.06) of the code that fixes this bug. > Another question: > > On client-side I use the method "MediaSubsession::getNormalPlayTime". All works fine for the first play-command. But after the send of a second play-command the method returns wrong values with the receive of a new RTCP "SR" packet. Whats going wrong? I don't know, because you haven't provided nearly enough information. Do both the RTSP client and the RTSP server use our code, or just the RTSP client? Please provide the complete RTSP protocol exchange (including both "PLAY" commands) between your client and your server, up to the point at which you believe the call to "getNormalPlayTime()" returns an incorrect result. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at metamachine.com Thu Sep 6 13:46:28 2012 From: owen at metamachine.com (owen at metamachine.com) Date: Thu, 6 Sep 2012 13:46:28 -0700 Subject: [Live-devel] live streaming media server bug report In-Reply-To: References: <2e47ab8853fa08bf37e4f788c24ce448.squirrel@www.metamachine.com> <33e755cd959cd29b70eb366625ea329c.squirrel@www.metamachine.com> Message-ID: Regarding casting between dissimilar types: > c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. > -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 > -Wall -DBSD=1 MatroskaFileParser.cpp > MatroskaFileParser.cpp: In member function ?Boolean > MatroskaFileParser::parseEBMLVal_float(EBMLDataSize&, float&)?: > MatroskaFileParser.cpp:1138:26: warning: dereferencing type-punned pointer > will break strict-aliasing rules [-Wstrict-aliasing] > MatroskaFileParser.cpp:1145:34: warning: dereferencing type-punned pointer > will break strict-aliasing rules [-Wstrict-aliasing] > > ... > No, this compiler warning message does not indicate a bug in the code. > "resultAsUnsigned" is a 4-byte value that stores a 'float'; it is not an > unsigned value that gets converted to a float. > > ... > > If you can suggest an alternative coding that eliminates your compiler > warning, then that would be great. But the code - as it stands - is not > in error. I've researched this, and it seems the right thing to do for this 'non-bug' is to add a compiler switch to tell it to be a little less aggressive in it's optimization so it doesn't generate incorrect code. The compiler flag is -fno-strict-aliasing. And yes, it will (not silently) generate incorrect code for certain uses of the construct. Here are a couple of cogent discussions on the issue: Linus dissing gcc: https://lkml.org/lkml/2003/2/26/158 A very thorough analysis of the issue: http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html A careful review of the above analysis: http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing/ // Wally From dennis.chan at myricom.com Thu Sep 6 14:25:26 2012 From: dennis.chan at myricom.com (Dennis Chan) Date: Thu, 6 Sep 2012 21:25:26 +0000 Subject: [Live-devel] Running Live555 Media Server with large number of clients Message-ID: <10235A7ACBF442498D584034010EB16811F6D74A@BL2PRD0411MB423.namprd04.prod.outlook.com> Hi, I am encountering a problem while trying to connect a large number of clients to the live555 Media Server. I have a single script which executes testRTSPClient in the background every .25 seconds and connects to the server to play a stream. When the number of clients reaches around 255, however, the server stops accepting connections. Clients become stuck at the DESCRIBE request. After a few seconds, it might accept 5-10 more, but then it completely stops. I noticed that the CPU usage was at 2% for 100 clients, 30% for 200 clients, but quickly ramped up to 100% once it reached 255 clients. This is all using the supplied code (2012.08.12). Is there any particular reason for the CPU usage exponentially increasing? Is there some limit to the number of client connections that I'm missing (I have checked my file limits)? Thank you for your time, Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 6 15:13:19 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Sep 2012 15:13:19 -0700 Subject: [Live-devel] Running Live555 Media Server with large number of clients In-Reply-To: <10235A7ACBF442498D584034010EB16811F6D74A@BL2PRD0411MB423.namprd04.prod.outlook.com> References: <10235A7ACBF442498D584034010EB16811F6D74A@BL2PRD0411MB423.namprd04.prod.outlook.com> Message-ID: > I am encountering a problem while trying to connect a large number of clients to the live555 Media Server. I have a single script which executes testRTSPClient in the background every .25 seconds and connects to the server to play a stream. When the number of clients reaches around 255, however, the server stops accepting connections. Clients become stuck at the DESCRIBE request. After a few seconds, it might accept 5-10 more, but then it completely stops. I noticed that the CPU usage was at 2% for 100 clients, 30% for 200 clients, but quickly ramped up to 100% once it reached 255 clients. Situations like this are almost always caused by the server process running into (or close to) the OS-imposed limit on the number of possible sockets it can have. If you increase this limit (this is something that you have to do inside the OS; not in the server code), then that should alleviate the problem (until you run into some other scalability limit, such as bandwidth :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rabbit.tv Thu Sep 6 16:09:27 2012 From: tim at rabbit.tv (Tim Zaitsev) Date: Thu, 06 Sep 2012 16:09:27 -0700 Subject: [Live-devel] Warning on MacOSX Message-ID: Ross, Line 73 in DelayQueue.hh throws a warning when compiling for macosx. include/DelayQueue.hh:73:41: Implicit conversion loses integer precision: 'time_base_seconds' (aka 'long') to '__darwin_suseconds_t' (aka 'int') fTv.tv_usec = useconds; tv_usec is of type __darwin_suseconds_t which is a typedef to __int32_t and that is a typedef to int I've temporarily surrounded it with but this may not be the cleanest fix: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wconversion" Timeval(time_base_seconds seconds, time_base_seconds useconds) { fTv.tv_sec = seconds; fTv.tv_usec = useconds; } #pragma GCC diagnostic pop Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 6 16:51:34 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Sep 2012 16:51:34 -0700 Subject: [Live-devel] live streaming media server bug report In-Reply-To: References: <2e47ab8853fa08bf37e4f788c24ce448.squirrel@www.metamachine.com> <33e755cd959cd29b70eb366625ea329c.squirrel@www.metamachine.com> Message-ID: <5FC9BDD7-FD58-4F5B-8B86-878E41232566@live555.com> While I doubt that - in practice - a compiler would generate incorrect code in this case, I agree that it's a possibility unless we compile with "-fno-strict-aliasing". But I don't want to do that, because it could make the whole of the code less efficient. (And changing the Makefiles to compile only this one file - "MatroskaFileParser.cpp" - with that flag would be messy.) However, reading through some of the comments at the bottom of , it's noted that one can get around strict aliasing restrictions by using "memcpy()". So, with this in mind, try the following alternative implementation of "MatroskaFileParser::parseEBMLVal_float()", and let us know if it makes your compiler happy: Boolean MatroskaFileParser::parseEBMLVal_float(EBMLDataSize& size, float& result) { unsigned resultAsUnsigned; if (!parseEBMLVal_unsigned(size, resultAsUnsigned)) return False; if (sizeof result != sizeof resultAsUnsigned) return False; memcpy(&result, &resultAsUnsigned, sizeof result); return True; } Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 6 17:03:35 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Sep 2012 17:03:35 -0700 Subject: [Live-devel] Warning on MacOSX In-Reply-To: References: Message-ID: > Line 73 in DelayQueue.hh throws a warning when compiling for macosx. That's odd; it doesn't for me. > I've temporarily surrounded it with but this may not be the cleanest fix: > > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wconversion" > Timeval(time_base_seconds seconds, time_base_seconds useconds) { > fTv.tv_sec = seconds; fTv.tv_usec = useconds; > } > #pragma GCC diagnostic pop The only problem with this is that it's GCC-specific; I'm unsure how other compilers (i.e., compilers other than GCC) might respond to those "#pragma"s. A better solution would be to add -DTIME_BASE=int to the COMPILE_OPTS line in "config.macosx", and then rerun "genMakefiles macosx" (and then recompile). If that works OK with you, then let us know, and I'll make this change (to "config.macosx") 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 joao_dealmeida at hotmail.com Wed Sep 5 23:43:24 2012 From: joao_dealmeida at hotmail.com (Joao Almeida) Date: Thu, 6 Sep 2012 06:43:24 +0000 Subject: [Live-devel] simulate RTP packet loss In-Reply-To: <5047A6EF.8030404@electricalscience.com> References: <5047A6EF.8030404@electricalscience.com> Message-ID: Try "Netem" netem provides Network Emulation functionality for testing protocols by emulating the properties of wide area networks. The current version emulates variable delay, loss, duplication and re-ordering. If you run a current 2.6 distribution, (Fedora, OpenSuse, Gentoo, Debian, Mandriva, Ubuntu), then netem is already enabled in the kernel and a current version of iproute2 is included. The netem kernel component is enabled under: Networking --> Networking Options --> QoS and/or fair queuing --> Network emulator Netem is controlled by the command line tool 'tc' which is part of the iproute2 package of tools. The tc command uses shared libraries and data files in the /usr/lib/tc directory. > Date: Wed, 5 Sep 2012 15:24:31 -0400 > From: stevens at electricalscience.com > To: live-devel at ns.live555.com > Subject: [Live-devel] simulate RTP packet loss > > Hi all, > > I would like to simulate packet loss of RTP packets on the network, and > I would like to use Live555 to do this. In fact, there already is some > code in MultiFramedRTPSink (in the > MultiFramedRTPSink::sendPacketIfNecessary() function) which is contained > in a "TEST_LOSS" macro, and is hardcoded to simulate 10% loss: > > #ifdef TEST_LOSS > if ((our_random()%10) != 0) // simulate 10% packet loss ##### > #endif > > I would like to do some more sophisticated testing (e.g. change the > packet loss to 5% or 25%). What is the "right" way to do this? Ideally > I would subclass MultiFramedRTPSink and then override the > sendPacketIfNecessary() function. But sendPacketIfNecessary() is > declared as "private" and so I cannot override. > > How best to simulate the packet loss without modifying the Live555 code > directly? > > Regards, > > --Andy Stevens > New York, USA > _______________________________________________ > 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 erduhai at qq.com Thu Sep 6 00:15:54 2012 From: erduhai at qq.com (=?gb18030?B?0fS6o7z+?=) Date: Thu, 6 Sep 2012 15:15:54 +0800 Subject: [Live-devel] live555 client behind a NAT Message-ID: When I test live555 (version 2012.02.03)client witch is behind a NAT box, RTSP commands have finished rightly, but client can not get any RTP data. (client RTP port:63339 NAT port:23356) My client RTP is over UDP.Since this live555 has add hole punching for client behind a NAT, why it doesn?t work?I have try to debug on server, and find that server have no response to dummy package(for NAT) from client.Should server change its destination port when it get the dummy package? rtsp server is rtsp://202.85.227.186:8554/webcam Thank you!Any reply is appreciation jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 6 19:32:13 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Sep 2012 19:32:13 -0700 Subject: [Live-devel] live555 client behind a NAT In-Reply-To: References: Message-ID: In general you can't reliably expect RTSP - clients or server - to work behind a NAT. (It can work for some kinds of NAT boxes, but if you find that it works at all, then you can consider yourself lucky.) However, you may be able to get RTP-over-TCP streaming to work. (To request RTP-over-TCP streaming, set the "streamUsingTCP" flag to True in your call to "sendSetupCommand()".) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From neilpep at gmail.com Thu Sep 6 00:30:05 2012 From: neilpep at gmail.com (Neil Pepper) Date: Thu, 6 Sep 2012 08:30:05 +0100 Subject: [Live-devel] Rendering a frame from H264 Message-ID: Hi Have been trying to use your excellent library to connect up to a camera that is streaming RTSP/H264 unicast from a source i have no control over. I seem to heading in right direction but I am struggling with the last bit, getting the frame from the library so i can display it to the screen. I have cloned testRTSPClient.cpp (using a non modified version assuringly i get packets from the video stream appearing in debug), below is modified version of continueAfterSETUP (have put in bold bits i have added), am i going in correct direction ? This also produces reassuring debug (added to bottom of email), am little worried about *The total received frame size exceed... *lines but whatever I change* *OutPacketBuffer::maxSize it seems to make no difference? To actually get the decoded frames I assumed I had to subclass * H264VideoStreamFramer *but cant see a way to actually get the frame, maybe implement new version of doGetNextFrame in class, but then processing stops as i cant call the base class version of continueReadProcessing as its private ? Any assistance would be appreciated . Perhaps if some sample code of retrieving a frame and rendering to the screen in any platform would help but i couldnt see any ? thanks in advance Neil void continueAfterSETUP(RTSPClient* rtspClient, int resultCode, char* resultString) { do { UsageEnvironment& env = rtspClient->envir(); // alias StreamClientState& scs = ((ourRTSPClient*)rtspClient)->scs; // alias if (resultCode != 0) { env << *rtspClient << "Failed to set up the \"" << *scs.subsession << "\" subsession: " << env.getResultMsg() << "\n"; break; } env << *rtspClient << "Set up the \"" << *scs.subsession << "\" subsession (client ports " << scs.subsession->clientPortNum() << "-" << scs.subsession->clientPortNum()+1 << ")\n"; * struct in_addr destinationAddress;* * destinationAddress.s_addr = our_inet_addr("0.0.0.0");* * * * const unsigned short rtpPortNum = 1234;* * const unsigned char ttl = 255;* * * * const Port rtpPort(rtpPortNum);* * * * Groupsock rtpGroupsock(env, destinationAddress, rtpPort, ttl);* * * * // Create a 'H264 Video RTP' sink from the RTP 'groupsock':* * OutPacketBuffer::maxSize = 100000;* * scs.subsession->sink = H264VideoRTPSink::createNew(env, &rtpGroupsock, 96);* * videoSource = H264VideoStreamFramer::createNew(env, scs.subsession->readSource());* // perhaps use your own custom "MediaSink" subclass instead if (scs.subsession->sink == NULL) { env << *rtspClient << "Failed to create a data sink for the \"" << *scs.subsession << "\" subsession: " << env.getResultMsg() << "\n"; break; } env << *rtspClient << "Created a data sink for the \"" << *scs.subsession << "\" subsession\n"; scs.subsession->miscPtr = rtspClient; // a hack to let subsession handle functions get the "RTSPClient" from the subsession scs.subsession->sink->startPlaying(*(*videoSource*), subsessionAfterPlaying, scs.subsession); // Also set a handler to be called if a RTCP "BYE" arrives for this subsession: if (scs.subsession->rtcpInstance() != NULL) { scs.subsession->rtcpInstance()->setByeHandler(subsessionByeHandler, scs.subsession); } } while (0); // Set up the next subsession, if any: setupNextSubsession(rtspClient); } *Opening connection to 192.168.42.1, port 554...* *...remote connection opened* *Sending request: DESCRIBE rtsp://192.168.42.1/AmbaStreamTest RTSP/1.0* ** *CSeq: 2* ** *User-Agent: drift (LIVE555 Streaming Media v2012.08.30)* ** *Accept: application/sdp* ** ** ** ** *Received 677 new bytes of response data.* *Received a complete DESCRIBE response:* *RTSP/1.0 200 OK* ** *CSeq: 2* ** *Date: Thu, Jan 01 1970 01:15:38 GMT* ** *Content-Base: rtsp://192.168.42.1/AmbaStreamTest/* ** *Content-Type: application/sdp* ** *Content-Length: 509* ** ** ** *v=0* ** *o=- 54670000 1 IN IP4 192.168.42.1* ** *s=Ambarella streaming* ** *i=Ambarella streaming* ** *t=0 0* ** *a=tool:Ambarella streaming 2012.03.12* ** *a=type:broadcast* ** *a=control:** ** *a=range:npt=0-* ** *a=x-qt-text-nam:Ambarella streaming* ** *a=x-qt-text-inf:Ambarella streaming* ** *m=video 0 RTP/AVP 96* ** *c=IN IP4 0.0.0.0* ** *b=AS:600* ** *a=rtpmap:96 H264/90000* ** *a=fmtp:96 packetization-mode=1;profile-level-id=4D4028;sprop-parameter-sets=AAAAASjuPIA=,AAAAASdNQCiaYoNj9gIgAAB9IAAdTByAAGmYAA0y9d5cZAADTMAAaZeu8uHcIhFBGAAAAA== * ** *a=control:track1* ** ** *[URL:"rtsp://192.168.42.1/AmbaStreamTest/"]: Got a SDP description:* *v=0* ** *o=- 54670000 1 IN IP4 192.168.42.1* ** *s=Ambarella streaming* ** *i=Ambarella streaming* ** *t=0 0* ** *a=tool:Ambarella streaming 2012.03.12* ** *a=type:broadcast* ** *a=control:** ** *a=range:npt=0-* ** *a=x-qt-text-nam:Ambarella streaming* ** *a=x-qt-text-inf:Ambarella streaming* ** *m=video 0 RTP/AVP 96* ** *c=IN IP4 0.0.0.0* ** *b=AS:600* ** *a=rtpmap:96 H264/90000* ** *a=fmtp:96 packetization-mode=1;profile-level-id=4D4028;sprop-parameter-sets=AAAAASjuPIA=,AAAAASdNQCiaYoNj9gIgAAB9IAAdTByAAGmYAA0y9d5cZAADTMAAaZeu8uHcIhFBGAAAAA== * ** *a=control:track1* ** ** *RTCPInstance[0x24eac0]::RTCPInstance()* *schedule(1.530479->1346841729.890146)* *[URL:"rtsp://192.168.42.1/AmbaStreamTest/"]: Initiated the "video/H264" subsession (client ports 59352-59353)* *Sending request: SETUP rtsp://192.168.42.1/AmbaStreamTest/track1 RTSP/1.0* ** *CSeq: 3* ** *User-Agent: drift (LIVE555 Streaming Media v2012.08.30)* ** *Transport: RTP/AVP;unicast;client_port=59352-59353* ** ** ** ** *Received 203 new bytes of response data.* *Received a complete SETUP response:* *RTSP/1.0 200 OK* ** *CSeq: 3* ** *Date: Thu, Jan 01 1970 01:15:38 GMT* ** *Transport: RTP/AVP;unicast;destination=192.168.42.3;source=192.168.42.1;client_port=59352-59353;server_port=6970-6971 * ** *Session: 5FAC6D41* ** ** ** ** *[URL:"rtsp://192.168.42.1/AmbaStreamTest/"]: Set up the "video/H264" subsession (client ports 59352-59353)* *[URL:"rtsp://192.168.42.1/AmbaStreamTest/"]: Created a data sink for the "video/H264" subsession* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *Sending request: PLAY rtsp://192.168.42.1/AmbaStreamTest/ RTSP/1.0* ** *CSeq: 4* ** *User-Agent: drift (LIVE555 Streaming Media v2012.08.30)* ** *Session: 5FAC6D41* ** *Range: npt=0.000-* ** ** ** ** *Received 189 new bytes of response data.* *Received a complete PLAY response:* *RTSP/1.0 200 OK* ** *CSeq: 4* ** *Date: Thu, Jan 01 1970 01:15:38 GMT* ** *Range: npt=0.000-* ** *Session: 5FAC6D41* ** *RTP-Info: url=rtsp:// 192.168.42.1/AmbaStreamTest/track1;seq=46686;rtptime=2944705573* ** ** ** ** *[URL:"rtsp://192.168.42.1/AmbaStreamTest/"]: Started playing session...* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *schedule(1.501818->1346841731.393142)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (11). 110 bytes of trailing data will be dropped!* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* *H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)* -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 6 20:07:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Sep 2012 20:07:24 -0700 Subject: [Live-devel] Rendering a frame from H264 In-Reply-To: References: Message-ID: > I have cloned testRTSPClient.cpp (using a non modified version assuringly i get packets from the video stream appearing in debug), below is modified version of continueAfterSETUP No, you're totally on the wrong track here. (For starters, the "H264VideoRTPSink" class is used only by *servers* - i.e., when *transmitting* H.264/RTP packets. It's completely irrelevant for you.) To update (a copy of) the "testRTSPClient" code so that it renders video data is fairly straightforward: You simply have to change the "DummySink" class, so that *it* does the rendering (or calls a decoder library to do the rendering). In particular, you would change the implementation of the "afterGettingFrame()" function - at line 479. That's it! (Actually, for H.264 video, there is one more thing that you'll probably need to do. H.264 streams have out-of-band configuration information (SPS and PPS NAL units) that you may need to feed to the decoder to initialize it. To get this information, call "MediaSubsession::fmtp_spropparametersets()" (on the video 'subsession' object). This will give you a (ASCII) character string. You can then pass this to "parseSPropParameterSets()", to generate binary NAL units for your decoder.) > am little worried about The total received frame size exceed... lines but whatever I change OutPacketBuffer::maxSize it seems to make no difference? I don't understand this. Changing "OutPacketBuffer::maxSize" - at runtime - should fix this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolai.vorontsov at quadrox.be Fri Sep 7 00:22:44 2012 From: nikolai.vorontsov at quadrox.be (Nikolai Vorontsov) Date: Fri, 7 Sep 2012 09:22:44 +0200 Subject: [Live-devel] simulate RTP packet loss In-Reply-To: <5047A6EF.8030404@electricalscience.com> References: <5047A6EF.8030404@electricalscience.com> Message-ID: Hello Andy, You better use the tool specifically designed for it: WanEm http://wanem.sourceforge.net/ There you can simulate packet loss, reordering, duplication, etc... Nikolai -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Andy Stevens Sent: Wednesday, September 05, 2012 9:25 PM To: live-devel at ns.live555.com Subject: [Live-devel] simulate RTP packet loss Hi all, I would like to simulate packet loss of RTP packets on the network, and I would like to use Live555 to do this. In fact, there already is some code in MultiFramedRTPSink (in the MultiFramedRTPSink::sendPacketIfNecessary() function) which is contained in a "TEST_LOSS" macro, and is hardcoded to simulate 10% loss: #ifdef TEST_LOSS if ((our_random()%10) != 0) // simulate 10% packet loss ##### #endif I would like to do some more sophisticated testing (e.g. change the packet loss to 5% or 25%). What is the "right" way to do this? Ideally I would subclass MultiFramedRTPSink and then override the sendPacketIfNecessary() function. But sendPacketIfNecessary() is declared as "private" and so I cannot override. How best to simulate the packet loss without modifying the Live555 code directly? Regards, --Andy Stevens New York, USA _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From zvyagintsev at atlantis.ru Fri Sep 7 00:25:29 2012 From: zvyagintsev at atlantis.ru (=?koi8-r?B?+tfRx8nOw8XXIOHO1M/O?=) Date: Fri, 7 Sep 2012 11:25:29 +0400 Subject: [Live-devel] Possible bug (and fix)? Message-ID: <007901cd8cc9$f5856e50$e0904af0$@ru> Hello. Don't know why but I cant post in my previous thread so I started another one. This is about the openrtsp/live555 problem on windows with the rtp over rtsp tcp channel. I've done some debugging and put additional debug output to live555 on incoming data handling. Take a look: :Skipped some RTSP related output: Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Session: d85 Started playing session Receiving streamed data... readSocket()=1, buffer[0]=36 readSocket()=1, buffer[0]=0 readSocket()=1, buffer[0]=5 readSocket()=1, buffer[0]=152 #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() readSocket()=1432 RTPInterface::handleRead() curBytesRead=1432 bytesRead=1432 totBytesToRead=1432 RTPInterface::handleRead() fNextTCPReadSize=0 #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #4 MultiFramedRTPSource::doGetNextFrame1() nextPacket != NULL readSocket()=1, buffer[0]=36 readSocket()=1, buffer[0]=0 readSocket()=1, buffer[0]=0 readSocket()=1, buffer[0]=232 #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() readSocket()=232 RTPInterface::handleRead() curBytesRead=232 bytesRead=232 totBytesToRead=232 RTPInterface::handleRead() fNextTCPReadSize=0 #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #4 MultiFramedRTPSource::doGetNextFrame1() nextPacket != NULL readSocket()=1, buffer[0]=36 readSocket()=1, buffer[0]=0 readSocket()=1, buffer[0]=5 readSocket()=1, buffer[0]=152 #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() readSocket()=1432 RTPInterface::handleRead() curBytesRead=1432 bytesRead=1432 totBytesToRead=1432 RTPInterface::handleRead() fNextTCPReadSize=0 #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #4 MultiFramedRTPSource::doGetNextFrame1() nextPacket != NULL #5 MultiFramedRTPSource::doGetNextFrame1() after nextPacket->use() frameSize=1419 fFrameSize=1419 #6 MultiFramedRTPSource::doGetNextFrame1() !fCurrentPacketCompletesFrame fFrameSize=1419 fMaxSize=262144 readSocket()=1, buffer[0]=36 readSocket()=1, buffer[0]=0 readSocket()=1, buffer[0]=5 readSocket()=1, buffer[0]=152 #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() readSocket()=1432 RTPInterface::handleRead() curBytesRead=1432 bytesRead=1432 totBytesToRead=1432 RTPInterface::handleRead() fNextTCPReadSize=0 #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #4 MultiFramedRTPSource::doGetNextFrame1() nextPacket != NULL #5 MultiFramedRTPSource::doGetNextFrame1() after nextPacket->use() frameSize=1418 fFrameSize=2837 #6 MultiFramedRTPSource::doGetNextFrame1() !fCurrentPacketCompletesFrame fFrameSize=2837 fMaxSize=260725 readSocket()=1, buffer[0]=36 readSocket()=1, buffer[0]=0 readSocket()=1, buffer[0]=5 readSocket()=1, buffer[0]=152 #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() readSocket()=44 RTPInterface::handleRead() curBytesRead=44 bytesRead=44 totBytesToRead=1432 RTPInterface::handleRead() fNextTCPReadSize=1388 fillInData() return false #3 MultiFramedRTPSource::doGetNextFrame1() #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header #3 MultiFramedRTPSource::doGetNextFrame1() #1 MultiFramedRTPSource::networkReadHandler1() before fillInData() #2 MultiFramedRTPSource::networkReadHandler1() before processing RTP header : repeated until break: Looks like after the fillInData returns false its hang in some kind of loop and stop to receive any futher data. Lets check the code of RTPInterdace::handleRead: } else { // Read from the TCP connection: bytesRead = 0; unsigned totBytesToRead = fNextTCPReadSize; if (totBytesToRead > bufferMaxSize) totBytesToRead = bufferMaxSize; unsigned curBytesToRead = totBytesToRead; int curBytesRead; while ((curBytesRead = readSocket(envir(), fNextTCPReadStreamSocketNum, &buffer[bytesRead], curBytesToRead, fromAddress)) > 0) { bytesRead += curBytesRead; if (bytesRead >= totBytesToRead) break; curBytesToRead -= curBytesRead; } fNextTCPReadSize -= bytesRead; if (fNextTCPReadSize == 0) { // We've read all of the data that we asked for readSuccess = True; } else if (curBytesRead <= 0) { // There was an error reading the socket bytesRead = 0; readSuccess = False; } else { // We need to read more bytes, and there was not an error reading the socket packetReadWasIncomplete = True; return True; } If I change } else if (curBytesRead <= 0) { to } else if (curBytesRead < 0) { openrtsp starts to working properly and receive data from stream. Is it a bug or I misunderstood something? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Fri Sep 7 00:43:48 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 07 Sep 2012 01:43:48 -0600 Subject: [Live-devel] H.264 in MPEG-2 TS streams roughly at the start Message-ID: <5049A5B4.1090300@etr-usa.com> We've been using live555MediaServer with MPEG-2 A/V in TS files successfully for quite some time now, but we are now experimenting with H.264 in TS. We've been unable to create files that stream as smoothly as our old MPEG-2 files. Here is my latest ffmpeg command attempt: ffmpeg -i original-mpeg2-version.ts -f mpegts -filter:v yadif \ -s hd720 -vcodec libx264 -profile:v high -b:v 8M \ -maxrate:v 15M -bufsize:v 12M -acodec ac3 -b:a 128k \ -flags cgop -fflags genpts h264-test.ts The result of that command is here, for your examination: http://etr-usa.com/live555/h264-test.ts (8 Mbit/s ? 1 MByte/min. File is 60 sec, 66 MB.) Both VLC and our STB are unhappy playing this via RTSP. (STB = The one we sent you months ago, Ross.) For the first 30 seconds or so, playback speed is badly controlled, as though Live555 isn't sending packets out at the right rate. After that, playback is mostly fine, though it does "blip" occasionally. VLC plays the file just fine straight off the disk. testMPEG2TransportStreamer exhibits the same stuttery playback symptom as live555MediaServer. (Yes, latest version: 2012.09.06.) Our ffmpeg build is up to date, too. Our tests started with a build from a git pull taken back in May, but re-pulling and rebuilding both ffmpeg and libx264 didn't result in materially different files. The -flags cgop (closed GOP) and -fflags genpts (regenerate PTS) options in the command above are desperation attempts, thinking maybe the problem is due to lack of some header or timing info. Neither helped, in combination or separately. That isn't surprising given that the .tsx file is nearly 4 MB. If timing or headers were the problem, we'd see a small or empty .tsx file, wouldn't we? Removing the .tsx file and restarting the RTSP server or RTP streamer doesn't change the symptom. The yadif filter and 720p options are there purely because the original MPEG-2 TS file is 1080i @ 59.94, 19.4 Mbit/s. Resizing and deinterlacing it is just part of our overall effort to get a smaller file, which also lead us to try switching to H.264. The remaining flags in the ffmpeg command have to do with ensuring the resulting file fits comfortably within the STB's limits. (HiP at 4.0) We've experimented with MP at 3.0 compliant encoding settings, with no effect on the symptom. That tells us the problem isn't one of too much data for the network or STB. We're taking a poorly-informed guess on the -bufsize parameter. The MPEG decoder chip inside the STB doesn't have a publicly available datasheet, and the STB's manufacturer doesn't document the VBV limits, other than to say "HiP at 4.0". That means up to a 25 Mbit buffer is legal, right? We've tried values between 6M and 18M here. The only effect we've seen is that if it gets too low, the stream won't play on the STB at all. So, we've lately been keeping the buffer to 1-2 seconds, changing the parameter to track the chosen average bit rate. We don't see why the -bufsize parameter would affect anything, given that VLC also shows the symptom. That suggests VBV limits have nothing to do with it, since VLC effectively has no VBV limits, right? Googling didn't bring up any recommended ffmpeg encoding settings for Live555. I haven't tried any of the standard ffmpeg presets, since those seem mainly aimed at low-spec cases, like Internet streaming or iPod video. Our usage scenario is LAN streaming from big RAIDs. Our ideal, with this move to H.264, is to get solid-quality HD video in space equivalent to high-quality SD. Say, 8-15 Mbit/s, 720p. We're not shooting for Criterion Collection BluRay quality here, just solid HD a step or two above YouTube/NetFlix/Hulu class "HD". I tell you all this in case it's our encoder settings causing the problem, so you can suggest changes that fit within our goals. If the fix is XP at 2.0, we're not interested. :) From jmdaa at iscte.pt Fri Sep 7 00:42:42 2012 From: jmdaa at iscte.pt (jmdaa at iscte.pt) Date: Fri, 07 Sep 2012 08:42:42 +0100 Subject: [Live-devel] SVC multi streaming transmission of separate layers Message-ID: Hi, In trying to solve a SVC multi streaming transmission of separate layers, using a standard MP4 container (i belive your server dont support this container). I manage to stream a mp4 container with two movie track on it, but to two different IP (using only one streaming server and two interface in the client). When we stream our MP4 container we get this with wireshark: No.,Time,Source,Destination,Protocol,Info 1,0.000000,195.134.1.2,195.134.1.6,RTSP,OPTIONSrtsp://195.134.1.6/spatialSoc_basenh3.mp4RTSP/1.0 2,0.000454,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 3,0.000607,195.134.1.2,195.134.1.6,RTSP,DESCRIBErtsp://195.134.1.6/spatialSoc_basenh3.mp4RTSP/1.0 4,0.002474,195.134.1.6,195.134.1.2,RTSP/SDP,Reply:RTSP/1.0200OK,withsessiondescription 5,0.004125,195.134.1.2,195.134.1.6,RTSP,SETUPRTSP://195.134.1.6/SPATIALSOC_BASENH3.MP4/TRACKID=65536RTSP/1.0 6,0.004885,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 7,0.005351,195.134.1.2,195.134.1.6,RTSP,SETUPRTSP://195.134.1.6/SPATIALSOC_BASENH3.MP4/TRACKID=65538RTSP/1.0 8,0.006363,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 9,0.006605,195.134.1.2,195.134.1.6,RTSP,PLAYrtsp://195.134.1.6/spatialSoc_basenh3.mp4/RTSP/1.0 10,0.007841,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 11,0.007854,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39746,Time=1652425076 12 ,0.007917,195.134.1.6,195.134.1.2,RTCP,SenderReportSourcedescriptionApplicationspecific(qtsi)subtype=1 13,0.007942,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39747,Time=1652425076 .......................... 24,0.009474,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39758,Time=1652425076,Mark 25,0.009487,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7486,Time=189610604 26,0.009524,195.134.1.6,195.134.1.2,RTCP,SenderReportSourcedescriptionApplicationspecific(qtsi)subtype=1 ......................................... 30,0.009566,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7490,Time=189610604 31,0.009571,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7491,Time=189610604,Mark DO YOU KNOW A WAY TO CHANGE THE SETUPRTSP IN YOUR CLIENT CODE (OPENRTSP) TO INDICATE THAT THE TWO TRACK GO TO TWO DIFFERENT IP (INTERFACE) FOR EXAMPLE: 4,0.002474,195.134.1.6,195.134.1.2,RTSP/SDP,Reply:RTSP/1.0200OK,withsessiondescription 5,0.004125,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.3/spatialSoc_basenh3.mp4/trackID=65536RTSP/1.0 6,0.004885,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 7,0.005351,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.6/spatialSoc_basenh3.mp4/trackID=65538RTSP/1.0 8,0.006363,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK Thks -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 7 01:44:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2012 01:44:23 -0700 Subject: [Live-devel] SVC multi streaming transmission of separate layers In-Reply-To: References: Message-ID: <358DBB64-5F0C-4BAC-B5B2-E9BEC8E08B65@live555.com> > Do you know a way to change the SETUPrtsp in your client code (openRTSP) to indicate that the two track go to two different IP (interface) for example: > 4,0.002474,195.134.1.6,195.134.1.2,RTSP/SDP,Reply:RTSP/1.0200OK,withsessiondescription > 5,0.004125,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.3/spatialSoc_basenh3.mp4/trackID=65536RTSP/1.0 > 6,0.004885,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK > 7,0.005351,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.6/spatialSoc_basenh3.mp4/trackID=65538RTSP/1.0 No - this makes no sense. The IP address (actually, it could also be a domain name) in the "rtsp://" URL that appears in a RTSP command (such as "SETUP") refers to an address on the *server*. It is not a client address. (Note that, in practice, because RTSP commands are sent over a TCP connection that has already been set up, these IP addresses (or domain names) in the "rtsp://" URLs are not actually looked at all by the server.) If you - as a RTSP client - want to specify that the stream should be sent to a *different* IP address from the IP address of the client, then the way to do this - in the RTSP protocol - is to include, in the "SETUP" command, a "Transport:" header that contains, e.g. destination=123.45.67.89; However, there are two big practical problems with doing this: 1/ Our RTSP client code does not support this (and there are no plans to do so). (Conceivably, you *might* be able to implement this by subclassing "RTSPClient", but it wouldn't be easy.) 2/ Most servers will not handle "destination=" parameters in a "SETUP" command's "Transport:" header, because it (i.e., allowing a client to specify some arbitrary 3rd party as being the stream's destination) is a security risk: It makes possible 'denial of service' attacks. Our server implementation does support this, but only if the compile-time macro RTSP_ALLOW_CLIENT_DESTINATION_SETTING is defined (see "RTSPServer.cpp", line 1282). But if your intention is to send the two video tracks to different interfaces within the same client, then the best way to do this is to keep things the way that they work now: Send both streams to the same (client) IP address, but with different port numbers. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.meding at ids-imaging.de Fri Sep 7 03:11:09 2012 From: m.meding at ids-imaging.de (Meding, Matthias) Date: Fri, 7 Sep 2012 12:11:09 +0200 Subject: [Live-devel] Filestreaming Message-ID: <4CB3F3483954BD4ABD0B4DBB35C7E33802BE28DB@exchsrv.idszentral.local> Hi Ross, thank you for your quick reply. My second topic was (and still is): >> On client-side I use the method "MediaSubsession::getNormalPlayTime". All works fine for the first play-command. But after the send of a second play-command the method returns wrong values with the receive of a new RTCP "SR" packet. Whats going wrong? > I don't know, because you haven't provided nearly enough information. Do both the RTSP client and the RTSP server use our code, or just the RTSP client? Please provide the complete RTSP protocol exchange (including both "PLAY" commands) between your client and your server, up to the point at which you believe the call to "getNormalPlayTime()" returns an incorrect result. On both sides I use live555. Protocol exchange (only client side): 1.) pRtspClient->sendPlayCommand(*m_pMediaSession, continueAfterPLAY, 0.0, -1.0, 1.0, m_pAuthenticator); Sending Request: PLAY xxx CSeq: xx User-Agent: xx Session: xxx Range: npt=0.000- Received a complete PLAY response RTSP/1.0 200 OK CSeq: xx Date: xxx Range: npt=0.000- Session: xxx RTP-Info: xxx 2.) pRtspClient->sendPauseCommand(*m_pMediaSession, continueAfterPAUSE, m_pAuthenticator); Sending Request: PAUSE xxx CSeq: xx User-Agent: xx Session: xxx Received a complete PAUSE response RTSP/1.0 200 OK CSeq: xx Date: xxx Session: xxx ------> all o.k. 3.) pRtspClient->sendPlayCommand(*m_pMediaSession, continueAfterPLAY, -1.0, -1.0, 1.0, m_pAuthenticator); Sending Request: PLAY xxx CSeq: xx User-Agent: xx Session: xxx Range: npt=0.000- Received a complete PLAY response RTSP/1.0 200 OK CSeq: xx Date: xxx Range: npt=0.000- Session: xxx RTP-Info: xxx ------> all o.k. until a RTCP "SR" packet sets the rtpTimestamp in "RTPReceptionStats::noteIncomingSR" Example: (after second PLAY command) ... presentationTime before NPT: 13469992513654 presentationTime after NPT: 10000000 presentationTime before NPT: 13469993513654 presentationTime after NPT: 1100000 presentationTime before NPT: 13469994513654 presentationTime after NPT: 1200000 presentationTime before NPT: 13469995513654 presentationTime after NPT: 1300000 ... new incoming "SR" packet ---> change the "fSyncTimestamp" in " RTPReceptionStats::noteIncomingSR" presentationTime before NPT: 13468215331451 presentationTime after NPT: -123045 ... It seems that the "fNPT_PTS_Offset" in "MediaSubsession::getNormalPlayTime" has a wrong value after the setting of "fSyncTimestamp"! double MediaSubsession::getNormalPlayTime(struct timeval const& presentationTime) { ... if (rtpInfo.infoIsNew) { // This is the first time we've been called with a synchronized presentation time since the "rtpInfo" // structure was last filled in. Use this "presentationTime" to compute "fNPT_PTS_Offset": if (seqNumLT(rtpSource()->curPacketRTPSeqNum(), rtpInfo.seqNum)) return -0.1; // sanity check; ignore old packets u_int32_t timestampOffset = rtpSource()->curPacketRTPTimestamp() - rtpInfo.timestamp; double nptOffset = (timestampOffset/(double)(rtpSource()->timestampFrequency()))*scale(); double npt = playStartTime() + nptOffset; fNPT_PTS_Offset = npt - ptsDouble*scale(); rtpInfo.infoIsNew = False; // for next time return npt; } else { // Use the precomputed "fNPT_PTS_Offset" to compute the NPT from the PTS: if (fNPT_PTS_Offset == 0.0) return 0.0; // error: The "rtpInfo" structure was apparently never filled in return (double)(ptsDouble*scale() + fNPT_PTS_Offset); } ... If I change the expression from "if (rtpInfo.infoIsNew)" to "if (True)" then "MediaSubsession::getNormalPlayTime" returns always the right value. Thanks in advance Matthias Meding -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevens at electricalscience.com Fri Sep 7 10:02:40 2012 From: stevens at electricalscience.com (Andy Stevens) Date: Fri, 07 Sep 2012 13:02:40 -0400 Subject: [Live-devel] simulate RTP packet loss Message-ID: <504A28B0.4000906@electricalscience.com> >> I would like to simulate packet loss of RTP packets on the network, >> and I would like to use Live555 to do this. In fact, there already >> is some code in MultiFramedRTPSink (in the >> MultiFramedRTPSink::sendPacketIfNecessary() function) which is >> contained in a "TEST_LOSS" macro, and is hardcoded to simulate 10% >> loss: >> >> #ifdef TEST_LOSS >> if ((our_random()%10) != 0) // simulate 10% packet loss >> ##### #endif >> >> I would like to do some more sophisticated testing (e.g. change the >> packet loss to 5% or 25%). What is the "right" way to do this? > > Normally I don't advise modifying the supplied code. However, > because you just want to simulate packet loss for testing (i.e., I > presume you don't plan on building a product that loses packets , > you might as well just modify the (#ifdef'd out) code that's already > there. > > E.g., if you want to simulate N% packet loss (where N is an integer > in the range [0,100], then you could change the "if" condition above > to if ((our_random()%100 >= N) // simulate N% packet loss Thanks Ross. But actually, I DO want to build it into the product. Because the product is portable, I want to be able to turn on the packet loss feature in the field, and for multiple installations. I also want to things like rearrange the packets so that they arrive in the wrong order, so I can be sure that they are being reordered properly. But I just wanted to be sure that there wasn't any C++ trick that I hadn't thought of that was preventing me from subclassing this properly so that I can overload the private functions. I guess that I am hacking the library more than the typical user. Also, C++ is not my best language (I'm more of a C and Java guy). --Andy Stevens From finlayson at live555.com Fri Sep 7 11:51:11 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2012 11:51:11 -0700 Subject: [Live-devel] simulate RTP packet loss In-Reply-To: <504A28B0.4000906@electricalscience.com> References: <504A28B0.4000906@electricalscience.com> Message-ID: <7DF6152A-D742-4737-8CDC-B5982A0A445C@live555.com> > Thanks Ross. But actually, I DO want to build it into the product. Because the product is portable, I want to be able to turn on the packet loss feature in the field, and for multiple installations. I also want to things like rearrange the packets so that they arrive in the wrong order, so I can be sure that they are being reordered properly. The server code is not really the best place to be doing this, and, in any case, I don't know of any way to do this in the server code without modifying it. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 7 15:25:48 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2012 15:25:48 -0700 Subject: [Live-devel] Possible bug (and fix)? In-Reply-To: <007901cd8cc9$f5856e50$e0904af0$@ru> References: <007901cd8cc9$f5856e50$e0904af0$@ru> Message-ID: <34DB1619-7799-4C49-A43D-6DC9A6CB8801@live555.com> Thanks for the report. I have now installed a new version (2012.09.07) that should fix the problem (with receiving RTP-over-TCP on Windows). (FYI: The bug got accidentally introduced back in version 2012.07.24, when we added a fix to better handle the disconnection of the remote end of TCP sockets. Unfortunately, however, that fix broke a separate, earlier workaround for a bug in Windows - so the Windows bug ended up accidentally reemerging. The latest version of the software should fix both. But this situation illustrates, yet again, that Windows is rapidly becoming more trouble than it's worth. I hope those of you who - for whatever reason - have chosen to develop only for Windows have an exit strategy in mind :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruno.Marchand at averna.com Fri Sep 7 15:22:04 2012 From: Bruno.Marchand at averna.com (Bruno Marchand) Date: Fri, 7 Sep 2012 18:22:04 -0400 Subject: [Live-devel] RTP timestamp issue after RTCP synchronization Message-ID: Hi! I am working on a RTSP recorder and proxy module using the live library. Basically, it is a module which streams from an Axis camera to a matroska file and supply a RTSP server for viewers. It is very similar to the software "live555ProxyServer" but with a matroska muxer. The camera generates two RTP streams, one H264 and one AAC. As far as I know, the live pipeline is the same as the one in "live555ProxyServer" with an added StreamReplicator just after the rtpSources. For each stream, the replicator streams in the RTSP server and in the matroska muxer. I had to create a few components for the matroska muxer and to "fit" the stream replicator in the RTSP server. At first, instead of a RSTP server, I created RTP sinks and connected VLC using a SDP. It worked well but letting VLC select its listening ports and adding RTCP appeared to me to be a good idea. I replaced RTP sinks by a RTSP server which worked well until I added the audio stream. In fact, the server properly stream data to VLC and VLC plays fine until the RTCP synchronisation occurs. It then spits these messages to the console: [00000000026b4bf8] main video output warning: picture is too late to be displayed (missing 131234696 ms) [00000000026b4bf8] main video output warning: picture is too late to be displayed (missing 131234664 ms) [00000000026b4bf8] main video output warning: picture is too late to be displayed (missing 131234632 ms) [00000000026b4bf8] main video output warning: picture is too late to be displayed (missing 131234600 ms) [00000000026b4bf8] main video output warning: picture is too late to be displayed (missing 131234568 ms) As you certainly already know, VLC uses live for rtp/rtsp streaming, so I tried to watch these streams using a program based on "testRTSPclient". The program displays the packets timestamps and adds an exclamation mark when not synchronized: Audio 2633490369 ! Video 2633490390 ! Video 2633490423 ! Audio 2633490433 ! Video 2633490457 ! Video 2633490490 ! Audio 2751915938 Video 2633490523 ! Video 2633490556 ! Audio 2751916002 Video 2633490590 ! Video 2633490623 ! Audio 2751916066 Video 2633490656 ! Video 2633490689 ! Audio 2751916130 Video 2633490723 ! Audio 2751916194 Video 2633490756 ! Video 2633490789 ! Audio 2751916258 Video 2633490823 ! Video 2633490856 ! Video 2633490889 ! Audio 2751916322 Audio 2751916386 Video 2633490922 ! Video 2633490956 ! Video 2633490989 ! Audio 2751916450 Video 2633491022 ! Video 2620681379 Audio 2751916514 Video 2620681413 Video 2620681446 Audio 2751916578 Video 2620681479 Video 2620681513 Audio 2751916642 Video 2620681546 Video 2620681579 Audio 2751916706 Video 2620681612 Video 2620681646 Audio 2751916770 Video 2620681679 Audio 2751916834 Video 2620681712 Video 2620681746 Video 2620681779 Audio 2751916890 As you can see, the timestamps (in milli sec) are in the same range before synchronization, but after synchronization, the gap VLC is complaining about appears. The gap is around 2751916890 - 2620681779 = 131235111. I'm still searching why RTCP create this gap. The issue is not the timestamp gap in one stream, but the difference between the synchronized timestamps of the two streams. The issue can be reproduced with an unmodified "live555ProxyServer". The SDP, exchanged through RTSP is v=0 o=- 1347046461812023 1 IN IP4 172.20.22.20 s=Session streamed by "VideoRecorder" i=av_stream 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:Session streamed by "VideoRecorder" a=x-qt-text-inf:av_stream m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50000 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=420029;sprop-parameter-sets=Z0IAKeKQGQJvy4C3AQEBpB4kRUA=,aM48gA== a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:32 a=rtpmap:97 MPEG4-GENERIC/16000 a=fmtp:97 streamtype=5;profile-level-id=15;mode=aac-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1408 a=control:track2 Any help will be appreciated. Thanks, Bruno Marchand -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 7 16:23:26 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2012 16:23:26 -0700 Subject: [Live-devel] RTP timestamp issue after RTCP synchronization In-Reply-To: References: Message-ID: <6A656F06-E78E-45BA-8653-82F4D65BF782@live555.com> > I?m still searching why RTCP create this gap. The issue is not the timestamp gap in one stream, but the difference between the synchronized timestamps of the two streams. > The issue can be reproduced with an unmodified ?live555ProxyServer?. For RTCP-based a/v synchronization to work properly for streams that are sent by the LIVE555 RTSP server implementation, two things have to be true: 1/ The presentation times for each frame have to be accurate (obviously), and 2/ The presentation times have to be aligned with 'wall-clock' time - i.e., times that would be generated by calling "gettimeofday()". This is also true for the proxy server (because it has a RTSP server inside it). So I think you have exposed a deficiency (bug) in the proxy server code - it is not ensuring that conditions 1/ and 2/ are true when it retransmits (i.e., relays) incoming frames. This is something that I'll need to fix. (Out of curiosity, does VLC play the stream OK (i.e., without any a/v sync problems) if you try playing it directly from the network camera (i.e., not through a proxy)?) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb at tmxvoip.com Fri Sep 7 14:47:46 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Sat, 8 Sep 2012 00:47:46 +0300 Subject: [Live-devel] Live555 iOs appstore licensing Message-ID: <4DA2BE3BF39942F7BF874D7FA6D0730E@work> hello for a application that's free in the iOs AppStore, would i need to buy a license for Live555 Media library ? thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From finlayson at live555.com Fri Sep 7 16:55:26 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2012 16:55:26 -0700 Subject: [Live-devel] Live555 iOs appstore licensing In-Reply-To: <4DA2BE3BF39942F7BF874D7FA6D0730E@work> References: <4DA2BE3BF39942F7BF874D7FA6D0730E@work> Message-ID: <7086ED14-75AB-4116-A7F6-87D60B989A8A@live555.com> > for a application that's free in the iOs AppStore, would i need to buy a license for Live555 Media library ? No. The LGPL copyright applies only to developers (who use the "LIVE555 Streaming Media" software), not to end users. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Fri Sep 7 20:45:39 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Sat, 8 Sep 2012 03:45:39 +0000 Subject: [Live-devel] Possible bug (and fix)? In-Reply-To: <34DB1619-7799-4C49-A43D-6DC9A6CB8801@live555.com> References: <007901cd8cc9$f5856e50$e0904af0$@ru>, <34DB1619-7799-4C49-A43D-6DC9A6CB8801@live555.com> Message-ID: Thanks for the report. I have now installed a new version (2012.09.07) that should fix the problem (with receiving RTP-over-TCP on Windows). Thanks a lot! (FYI: The bug got accidentally introduced back in version 2012.07.24, when we added a fix to better handle the disconnection of the remote end of TCP sockets. Unfortunately, however, that fix broke a separate, earlier workaround for a bug in Windows - so the Windows bug ended up accidentally reemerging. The latest version of the software should fix both. But this situation illustrates, yet again, that Windows is rapidly becoming more trouble than it's worth. I hope those of you who - for whatever reason - have chosen to develop only for Windows have an exit strategy in mind :-) In many cases, at least on the client side, Windows is the only viable option. I definitely wouldn't mind if >50% were using a Linux flavor as desktop OS, but today that's not the case. I just want to say that I'm, and I'm sure many with me, are thankful as long as you support Windows. /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 7 21:13:29 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2012 21:13:29 -0700 Subject: [Live-devel] H.264 in MPEG-2 TS streams roughly at the start In-Reply-To: <5049A5B4.1090300@etr-usa.com> References: <5049A5B4.1090300@etr-usa.com> Message-ID: <2FD4949D-3D7F-48E7-AB80-97701C3F42C4@live555.com> > We've been using live555MediaServer with MPEG-2 A/V in TS files successfully for quite some time now, but we are now experimenting with H.264 in TS. We've been unable to create files that stream as smoothly as our old MPEG-2 files. Our code has trouble streaming MPEG Transport Stream files that are extremely VBR (variable bit rate), which is what I suspect your file is. The problem is the "MPEG2TransportStreamFramer" class. This class uses the stream's PCR timestamps to compute (estimate) the duration of each of the (188-byte) Transport Stream 'packet' that pass through it, before they get packed into larger RTP packets and transmitted. These packet durations determine the rate at which the RTP packets get sent. Unfortunately, it's difficult to compute accurate duration estimates for VBR streams; consequently, the estimated duration sometimes gets too large, which means that some packets get delivered too slowly for the receiver (i.e., underflow). Alternatively, the estimated duration sometimes gets too small, which means that some packets will get delivered too quickly for the receiver (overflow, or even packet loss). The basic problem is that the "MPEG2TransportStreamFramer" class doesn't 'read ahead' through the incoming Transport Stream data, so it doesn't have any 'future' PCR timestamps to work from as it computes estimated durations; instead, it can work only from PCR timestamps that it has already seen. One way to overcome problems streaming VBR files is to reencode them so that they're 'less VBR'. Unfortunately, this will likely increase the file's size, and thus the stream's bitrate. Another possibility is to tweak (e.g., using compile-line definitions) some of the four constants NEW_DURATION_WEIGHT TIME_ADJUSTMENT_FACTOR MAX_PLAYOUT_BUFFER_DURATION PCR_PERIOD_VARIATION_RATIO to try to get better performance. Unfortunately, this is somewhat of a 'black art', and there's no guarantee that this will improve things. Down the road, a better solution might be to provide an alternative implementation of the "MPEG2TransportStreamFramer" class that 'reads ahead' (i.e., buffers some input transport data), so that it can look one PCR timestamp ahead, thereby producing more accurate duration estimates. The disadvantage of this, however, is that it would be less efficient than the current "MPEG2TransportStreamFramer" implementation (which doesn't buffer any input data at all). Another possibility would be store packet durations in the 'index file' (that gets used when performing 'trick play' operations on Transport Stream files. The disadvantage of this, however, is that it would work only for prerecorded files, not 'live' input streams (e.g., from an encoder). It would also require an incompatible change to the index file format. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From qiuchangyong at gmail.com Fri Sep 7 00:06:26 2012 From: qiuchangyong at gmail.com (qiuchangyong qiuchangyong) Date: Fri, 7 Sep 2012 15:06:26 +0800 Subject: [Live-devel] report a bug of openRTSP Message-ID: I try to use openRTSP to dump the rtsp stream to AVI file with command like this "openRTSP -i w 352 -h 288 -f 25 rtsp://xxxx", where xxxx is the real rtsp url, I've also change the code of "playCommon.cpp" in the line : *aviOut = AVIFileSink::createNew(*env, *session, "stdout",* to *aviOut = AVIFileSink::createNew(*env, *session, "openRTSP.avi"* i can get the file, but it couldnot play, then i check the content of openRTSP.avi file, find that the h264 start code is missing(the video codec from stream is avc"). so i add something to AVIFileSink.cpp, useFrame, like this " fOurSink.fNumBytesWritten += fOurSink.addWord(fAVISubsessionTag); *if (strcmp(fOurSubsession.codecName(), "H264") == 0)//daniel hack { fOurSink.fNumBytesWritten += fOurSink.addWord(frameSize+4); fOurSink.fNumBytesWritten += fOurSink.addWord(fourChar(0x00, 0x00, 0x00, 0x01));//add start code } else fOurSink.fNumBytesWritten += fOurSink.addWord(frameSize); * fwrite(frameSource, 1, frameSize, fOurSink.fOutFid); then it works, but still have an issue, the avi file generated can be played in vlc, but cannot be played in Windows Media Player. maybe the lack of index is the cause, i will investigate it later. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 7 22:03:02 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2012 22:03:02 -0700 Subject: [Live-devel] report a bug of openRTSP In-Reply-To: References: Message-ID: <7957C35F-6D0D-4801-A5EC-68140A418A5F@live555.com> > I try to use openRTSP to dump the rtsp stream to AVI file with command like this "openRTSP -i w 352 -h 288 -f 25 rtsp://xxxx", where xxxx is the real rtsp url, I've also change the code of "playCommon.cpp" in the line : > aviOut = AVIFileSink::createNew(*env, *session, "stdout", > to aviOut = AVIFileSink::createNew(*env, *session, "openRTSP.avi" You don't need to do this. Instead, just do openRTSP -i w 352 -h 288 -f 25 rtsp://xxxx > openRTSP.avi i.e., redirect 'stdout' to a file on the command line. > i can get the file, but it couldnot play, then i check the content of openRTSP.avi file, find that the h264 start code is missing(the video codec from stream is avc"). > so i add something to AVIFileSink.cpp, useFrame, like this Thanks. I will include this change in the next version of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 7 23:21:57 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2012 23:21:57 -0700 Subject: [Live-devel] Filestreaming In-Reply-To: <4CB3F3483954BD4ABD0B4DBB35C7E33802BE28DB@exchsrv.idszentral.local> References: <4CB3F3483954BD4ABD0B4DBB35C7E33802BE28DB@exchsrv.idszentral.local> Message-ID: I tried reproducing what you did - by using a modified version of "testRTSPClient" that - plays a stream for 5 seconds - pauses for 7 seconds - plays the stream again (starting from 0, as you did[*]) (It also prints out the NPT time (along with the presentation time) for each received frame.) However, I didn't see anything wrong with the NPT values at any time. FYI, I have attached my modified "testRTSPClient.cpp" to this message. Feel free to compile and run it for yourself. However, I'm curious about what you've written here: > presentationTime before NPT: 13469992513654 > presentationTime after NPT: 10000000 (etc.) This suggests to me that perhaps you don't quite understand the difference between "presentation time" and "normal play time" (aka. NPT). They are *different* times, with *different* time scales, so it doesn't make sense to talk about "presentationTime before NPT" or "presentationTime after NPT". "presentation time" (in seconds and microseconds) indicates a (relative) time at which each frame should be fed to a decoder. "normal play time" (NPT) indicates the current 'human readable' position in the stream. I.e., think of it as being like the play time shown on the front of a VCR, if you had a VCR playing the stream. (Also, neither time is an integer, so I don't know why you've written integers above.) [*] Actually, your second call to "sendPlayCommand()" specified a start time of -1.0 (which got converted to 0.0). I don't know why you did that... 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: testRTSPClient.cpp Type: application/octet-stream Size: 21479 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb at tmxvoip.com Sat Sep 8 01:06:48 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Sat, 8 Sep 2012 11:06:48 +0300 Subject: [Live-devel] Live555 iOs appstore licensing References: <4DA2BE3BF39942F7BF874D7FA6D0730E@work> <7086ED14-75AB-4116-A7F6-87D60B989A8A@live555.com> Message-ID: <850F91630C994D4EA0F69EA6B900722F@work> no no, i'm not an end user, but i'm developing a app that would be free in the AppStore i hope you got it ;) thank you ----- Original Message ----- From: "Ross Finlayson" To: "LIVE555 Streaming Media - development & use" Sent: Saturday, September 08, 2012 2:55 AM Subject: Re: [Live-devel] Live555 iOs appstore licensing > for a application that's free in the iOs AppStore, would i need to buy a > license for Live555 Media library ? No. The LGPL copyright applies only to developers (who use the "LIVE555 Streaming Media" software), not to end users. Ross Finlayson Live Networks, Inc. http://www.live555.com/ __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------------------------------------------------------------------------- > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From info at nnuvo.org Sun Sep 9 04:20:41 2012 From: info at nnuvo.org (johan) Date: Sun, 9 Sep 2012 11:20:41 +0000 (UTC) Subject: [Live-devel] NAL processing order. Message-ID: I am currently sending NAL packets with the following setup, server side. This stream is H264 AVC format. I am delivering single NAL units (With AVC start codes) to H264VideoStreamDiscreteFramer from a Device subclass which in turn feeds to a H264VideoRTPSink; The H264VideoRTPSink is initiated with the proper sps pps settings. (The avc format i am working with seems to have a static set) all is well in delivery except when the NAL's look like MPEG NALS 00 00 xx xx. (warning nal type:0) You had mentioned in a previous question there should be no start codes, however the decoder (client side) certainly requires it for immediate play. Are the start codes somehow reconstructed client side with a proper setup? Does this include h264 parsing like combining slice NAL's or am I on my own for this. This is what the sprops / sps pps are intended to do... But I have been unsuccessful in doing this client side for decoder prep. My guess would be feeding the stream too an h264FileSink or H264VideoRTPSource and then trying the output from that. Any advice would be great, little stumped. From finlayson at live555.com Sun Sep 9 08:04:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Sep 2012 08:04:23 -0700 Subject: [Live-devel] NAL processing order. In-Reply-To: References: Message-ID: > This stream is H264 AVC format. I am delivering single NAL units > (With AVC start codes) to H264VideoStreamDiscreteFramer No! You MUST NOT include 'start codes' (i.e., 0x00 0x00 0x00 0x01) in the NAL units that you feed to a "H264VideoStreamDiscreteFramer". I don't know how much clearer I (and the LIVE555 code) can be about this! > from a > Device subclass which in turn feeds to a H264VideoRTPSink; [...] > all is well in delivery except when the NAL's look like MPEG NALS > 00 00 xx xx. (warning nal type:0) FYI, you may be using an out-of-date version of our software. If so, please upgrade. > You had mentioned in a > previous question there should be no start codes, however the > decoder (client side) certainly requires it for immediate play. That's irrelevant! We're not talking about feeding NAL units to a client; we're talking about feeding them to a "H264VideoStreamDiscreteFramer", which in turn gets fed to a "H264VideoRTPSink", which in turn get transmitted within RTP packets (which according to the IETF-defined payload format for H.264, MUST NOT include start codes). This all happens at the *sender* end - i.e., the server. Once again, the NAL units that you feed to a "H264VideoStreamDiscreteFramer" MUST NOT include start codes. > Are the start codes somehow reconstructed client side with a > proper setup? The *receiver* end - i.e., the client - receives NAL units that have been packed into RTP packets. Once again, according to the IETF-defined standard payload format for H.264, these NAL units DO NOT include start codes. Instead, the receiving client receives - from the RTP demultiplexor - a sequence of discrete NAL units, each with their size defined. (I.e., the receiving client doesn't need (and doesn't get) start codes, because instead it knows the size of each NAL unit.) If the receiver also uses the LIVE555 software, then it would use a "H264VideoRTPSource", which (like all "FramedSource" subclasses) delivers a sequence of 'frames', each with its own length ("frameSize"). In this case, each such 'frame' is a H.264 NAL unit (without a start code). These NAL units would then be fed to a decoder. If the decoder needs a start code in front of each NAL unit, then you would insert it there - i.e., when you feed it to your decoder. If, however, the decoder doesn't need a start code - i.e., if the NAL unit lengths are enough for the decoder - then you don't need to insert one when you feed it to your decoder. I.e., it depends on your decoder. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From schamschurko at medialan.de Sun Sep 9 12:21:04 2012 From: schamschurko at medialan.de (Dmitri Schamschurko) Date: Sun, 09 Sep 2012 21:21:04 +0200 Subject: [Live-devel] Problem using MPEG1or2VideoStreamDiscreteFramer Message-ID: <504CEC20.3050907@medialan.de> Hello Ross, thank you for your great work. I am new here and have a question which I could not answer even after reading the Live555 mailing archive carefully. Could you please help me with the following points in relation to MPEG-2 streaming from a live source. I implemented my own MPEG-2 device source based on your device source sample and the event trigger mechanism. I use MPEG1or2VideoStreamDiscreteFramer as a filter because I get the data from my source as individual frames (I-, P- and B-pictures). That works quite well. But I have problems with the understanding when and how to inject Sequence headers. My source provides I-frames which have a sequence header in front of each of them. When I checked the RTP stream with Wireshark I found that the picture type of the I-picture in the RTP header (RFC2250 MPEG1) is not correct. The picture type field of the RTP header is always 0 (forbidden) or the last picture type which was transmitted. If the last transmitted picture was a B-picture the I-picture is identified as well as B-picture (type 3) in the RTP header. The same holds for the temporal_reference value of the I-picture. It is the same as that of the last B-picture which was sent. That happens if the I-picture contains a sequence header at its start. If I remove the sequence headers ? the I-picture starts now with a picture start marker ? then everything seems to be ok ? except for the very first I-frame which starts the streaming. It must still contain the sequence header. Otherwise the stream cannot be replayed. With that the very first I-frame gets the picture type 0 (forbidden) as mentioned above. Am I doing anything wrong? Should the sequence header sent separated from the picture? Am I to send sequence headers at all? What is the right strategy to refresh sequence header information regularly? Additionally the MPEG1or2VideoStreamDiscreteFramer has the parameter vshPeriod. I used the default of 5 and stripped all Sequence headers off from the I-pictures except the very first one to provide that information to the framer at all. But when inspecting the stream I could see the sequence header just ones (with the very first I-frame). Shouldn?t it be injected regularly with the vshPeriod of the discrete framer. Currently I have some jerking effects in the replay which is probably caused by the wrong information in the RTP headers (my assumption). That?s why I analyzed that a bit more in depth. Best regards Dmitri From finlayson at live555.com Sun Sep 9 17:13:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Sep 2012 17:13:24 -0700 Subject: [Live-devel] Problem using MPEG1or2VideoStreamDiscreteFramer In-Reply-To: <504CEC20.3050907@medialan.de> References: <504CEC20.3050907@medialan.de> Message-ID: <6F22DD72-7A5E-403E-A34A-5B354076FA87@live555.com> Dmitri, > I implemented my own MPEG-2 device source based on your device source sample > and the event trigger mechanism. I use MPEG1or2VideoStreamDiscreteFramer as a > filter because I get the data from my source as individual frames (I-, P- and > B-pictures). That works quite well. First, I assume that you are feeding the output from your "MPEG1or2VideoStreamDiscreteFramer" into a "MPEG1or2VideoRTPSink" (which implements the RFC 2250 RTP payload format for MPEG-1 or 2 video). I don't know why Wireshark claims to be reporting bad RTP packets; perhaps Wireshark is in error? FYI, the (4-byte) video special header at the front of the RTP packet is set on line 144 of "MPEG1or2VideoRTPSink.cpp". > But I have problems with the understanding when and how to inject Sequence > headers. My source provides I-frames which have a sequence header in front of > each of them. This is good. > If I remove the sequence headers ? the I-picture starts now with a picture > start marker ? then everything seems to be ok ? except for the very first > I-frame which starts the streaming. It must still contain the sequence header. > Otherwise the stream cannot be replayed. With that the very first I-frame > gets the picture type 0 (forbidden) as mentioned above. This suggests to me that Wireshark is in error (assuming, of course, that you are feeding your "MPEG1or2VideoStreamDiscreteFramer" into a "MPEG1or2VideoRTPSink", and not something else (like a "SimpleRTPSink")). > Additionally the MPEG1or2VideoStreamDiscreteFramer has the parameter vshPeriod. > I used the default of 5 and stripped all Sequence headers off from the > I-pictures except the very first one to provide that information to the framer > at all. But when inspecting the stream I could see the sequence header just > ones (with the very first I-frame). Shouldn?t it be injected regularly > with the vshPeriod of the discrete framer. Yes, it should. The "vshPeriod" parameter specifies the *maximum* time period until a (the most recently seen) Video Sequence Header will be reinserted in the output stream. However, if your I-frames all begin with Video Sequence Headers, then this should be irrelevant (assuming that your I-frames occur more frequently than once every 5 seconds). One other thing that you should check: Make sure that you are setting "fPresentationTime" properly in your input source class (i.e., your class that's based upon the "DeviceSource" code). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at nnuvo.org Sun Sep 9 19:57:41 2012 From: info at nnuvo.org (johan) Date: Mon, 10 Sep 2012 02:57:41 +0000 (UTC) Subject: [Live-devel] NAL processing order. References: Message-ID: Ross Finlayson writes: > No! ?You MUST NOT include 'start codes' (i.e., 0x00 0x00 0x00 0x01) > in the NAL units that you feed to a "H264VideoStreamDiscreteFramer". > I don't know how much clearer I (and the LIVE555 code) can be about > this! Sorry let me be more precise, I meant AVC nal lengths, which I was (incorrectly) referring too as start codes of the AVC format. I definitely get that annex-b start codes should not be sent to the Framer, it can be clearly seen in the code, but i am not sure if the framer requires the AVC NAL lengths which precede the Nal data for each NAL Unit. > all is well in delivery except when the NAL's look like MPEG NALS > 00 00 ?xx xx. (warning nal type:0) Happening when I include the AVC NAL Lengths. > The *receiver* end - i.e., the client - receives NAL units that have > been packed into RTP packets. ?Once again, according to the > IETF-defined standard payload format for H.264, these NAL units > DO NOT include start codes. ?Instead, the receiving client receives > - from the RTP demultiplexor - a sequence of discrete NAL units, > each with their size defined. ?(I.e., the receiving client doesn't need > (and doesn't get) start codes, because instead it knows the size > of each NAL unit.) Ill try to *decipher* the RTP IETF Docs. Thanks for your help. From finlayson at live555.com Sun Sep 9 20:13:01 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Sep 2012 20:13:01 -0700 Subject: [Live-devel] NAL processing order. In-Reply-To: References: Message-ID: >> No! You MUST NOT include 'start codes' (i.e., 0x00 0x00 0x00 0x01) >> in the NAL units that you feed to a "H264VideoStreamDiscreteFramer". >> I don't know how much clearer I (and the LIVE555 code) can be about >> this! > > Sorry let me be more precise, I meant AVC nal lengths, which I was > (incorrectly) referring too as start codes of the AVC format. I definitely > get that annex-b start codes should not be sent to the Framer, it can be > clearly seen in the code, but i am not sure if the framer requires the AVC > NAL lengths which precede the Nal data for each NAL Unit. No, you just feed the "H264VideoStreamDiscreteFramer" the NAL unit data itself. The "H264VideoStreamDiscreteFramer" doesn't need any in-band length field, because you specify the length ("fFrameSize") separately when you deliver each frame (i.e., NAL unit) to it, and the "H264VideoStreamDiscreteFramer" gets the length (as a separate parameter) whenever it receives each frame (i.e. NAL unit). > Ill try to *decipher* the RTP IETF Docs. You don't need to do this, because we (the "LIVE555 Streaming Media" software) have implemented these RTP payload formats for you. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lijing0010 at gmail.com Sat Sep 8 06:38:16 2012 From: lijing0010 at gmail.com (jing li) Date: Sat, 8 Sep 2012 21:38:16 +0800 Subject: [Live-devel] Is this a known issue in MPEG2TransportStreamFromESSource? Message-ID: Hi I'm trying to streaming a ts from from 264 es stream, the pipeline is like: ByteStreamFileSource->H264VideoStreamFramer->MPEG2TransportStreamFromESSource->MPEG2TransportStreamFramer. While at the end of playback, there's a little chance to crash. In MPEG2TransportStreamFromESSource.cpp, void MPEG2TransportStreamFromESSource::awaitNewBuffer(unsigned char* oldBuffer) There's a piece of code like: -------------------------------- ... // No filled-in buffers are available. Ask each of our inputs for data: for (sourceRec = fInputSources; sourceRec != NULL; sourceRec = sourceRec->next()) { sourceRec->askForNewData(); } ---------------------------------------- After sourceRec->askForNewData(), the sourceRec may be destructed, and the "sourceRec=sourceRec->next()" will be a wild pointer. I'm not sure if I'm wrong or this has been reported before. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Sep 9 21:35:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Sep 2012 21:35:38 -0700 Subject: [Live-devel] Is this a known issue in MPEG2TransportStreamFromESSource? In-Reply-To: References: Message-ID: <98395617-52ED-42C3-86EC-D347A77CA9C1@live555.com> > I'm trying to streaming a ts from from 264 es stream, the pipeline is like: > ByteStreamFileSource->H264VideoStreamFramer->MPEG2TransportStreamFromESSource->MPEG2TransportStreamFramer. > While at the end of playback, there's a little chance to crash. > > In MPEG2TransportStreamFromESSource.cpp, > void MPEG2TransportStreamFromESSource::awaitNewBuffer(unsigned char* oldBuffer) > There's a piece of code like: > -------------------------------- > ... > // No filled-in buffers are available. Ask each of our inputs for data: > for (sourceRec = fInputSources; sourceRec != NULL; > sourceRec = sourceRec->next()) { > sourceRec->askForNewData(); > } > ---------------------------------------- > > After sourceRec->askForNewData(), the sourceRec may be destructed, and the "sourceRec=sourceRec->next()" will be a wild pointer. Yes, this can happen, if (and only if) the "MPEG2TransportStreamFromESSource" object gets deleted while we're in the loop. To fix this, change the "MPEG2TransportStreamFromESSource::~MPEG2TransportStreamFromESSource()" implementation from delete fInputSources; to doStopGettingFrames(); delete fInputSources; Thank you for the report. This fix will be included in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at simonmaddox.com Mon Sep 10 01:04:42 2012 From: simon at simonmaddox.com (Simon Maddox) Date: Mon, 10 Sep 2012 09:04:42 +0100 Subject: [Live-devel] playSIP Authentication Error Message-ID: <98CC3B74684846188B7D30EE540172D2@simonmaddox.com> I came across playSIP, and it appears to do exactly what I'm after. However? No matter what I do, I always get a 407 Proxy Authentication Required. I've checked around line 493 of SIPClient.cpp, and confirmed that the realm and nonce are being parsed correctly. Assuming this might be the fault of my SIP provider, I ran a default installation of Freeswitch on my local machine, and I'm still having issues. I've logged into the account "1000" with a SIP client, and that rings when I run playSIP, but I still get the same issue. Logging into "1001" with a SIP client and calling 1000 produces the correct outcome (rings, answer, media is transferred). I've included my console output below - does anyone know what's going on? Cheers, Simon ------ $ playSIP -u 1001 1234 sip:1000 at 192.168.1.14 Sending request: INVITE sip:1000 at 192.168.1.14 SIP/2.0 From: 1001 ;tag=758580961 Via: SIP/2.0/UDP 192.168.1.14:34553 To: sip:1000 at 192.168.1.14 Contact: sip:1001 at 192.168.1.14:34553 Call-ID: 1545070494 at 192.168.1.14 CSeq: 1 INVITE Content-Type: application/sdp User-Agent: playSIP (LIVE555 Streaming Media v2011.07.21) Content-Length: 116 v=0 o=- 1545070494 0 IN IP4 192.168.1.14 s=playSIP session c=IN IP4 192.168.1.14 t=0 0 m=audio 8000 RTP/AVP 0 Received INVITE response: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.14:34553 From: 1001 ;tag=758580961 To: Call-ID: 1545070494 at 192.168.1.14 CSeq: 1 INVITE User-Agent: FreeSWITCH-mod_sofia/1.3.0+git~20120906T224301Z~a7c791d2de Content-Length: 0 Received INVITE response: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 192.168.1.14:34553 From: 1001 ;tag=758580961 To: ;tag=Dj9FF476vey0p Call-ID: 1545070494 at 192.168.1.14 CSeq: 1 INVITE User-Agent: FreeSWITCH-mod_sofia/1.3.0+git~20120906T224301Z~a7c791d2de Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Proxy-Authenticate: Digest realm="192.168.1.14", nonce="a9cc8540-f8d8-11e1-a32f-97553ec22995", algorithm=MD5, qop="auth" Content-Length: 0 Sending request: INVITE sip:1000 at 192.168.1.14 SIP/2.0 From: 1001 ;tag=758580961 Via: SIP/2.0/UDP 192.168.1.14:34553 To: sip:1000 at 192.168.1.14 Contact: sip:1001 at 192.168.1.14:34553 Call-ID: 1545070494 at 192.168.1.14 CSeq: 2 INVITE Content-Type: application/sdp Proxy-Authorization: Digest username="1001", realm="192.168.1.14", nonce="a9cc8540-f8d8-11e1-a32f-97553ec22995", response="ce3a0885091a2c89d60257fa9e564273", uri="sip:1000 at 192.168.1.14" User-Agent: playSIP (LIVE555 Streaming Media v2011.07.21) Content-Length: 116 v=0 o=- 1545070494 1 IN IP4 192.168.1.14 s=playSIP session c=IN IP4 192.168.1.14 t=0 0 m=audio 8000 RTP/AVP 0 Received INVITE response: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.14:34553 From: 1001 ;tag=758580961 To: Call-ID: 1545070494 at 192.168.1.14 CSeq: 2 INVITE User-Agent: FreeSWITCH-mod_sofia/1.3.0+git~20120906T224301Z~a7c791d2de Content-Length: 0 Received INVITE response: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 192.168.1.14:34553 From: 1001 ;tag=758580961 To: ;tag=eU28gZratQmKj Call-ID: 1545070494 at 192.168.1.14 CSeq: 2 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.3.0+git~20120906T224301Z~a7c791d2de Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 191 Remote-Party-ID: "1000" ;party=calling;privacy=off;screen=no v=0 o=FreeSWITCH 1346991036 1346991037 IN IP4 192.168.1.14 s=FreeSWITCH c=IN IP4 192.168.1.14 t=0 0 m=audio 23488 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 Received INVITE response: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 192.168.1.14:34553 From: 1001 ;tag=758580961 To: ;tag=Dj9FF476vey0p Call-ID: 1545070494 at 192.168.1.14 CSeq: 1 INVITE User-Agent: FreeSWITCH-mod_sofia/1.3.0+git~20120906T224301Z~a7c791d2de Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Proxy-Authenticate: Digest realm="192.168.1.14", nonce="a9cc8540-f8d8-11e1-a32f-97553ec22995", algorithm=MD5, qop="auth" Content-Length: 0 Failed to get a SDP description from URL "sip:1000 at 192.168.1.14": (NULL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 01:22:50 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 01:22:50 -0700 Subject: [Live-devel] playSIP Authentication Error In-Reply-To: <98CC3B74684846188B7D30EE540172D2@simonmaddox.com> References: <98CC3B74684846188B7D30EE540172D2@simonmaddox.com> Message-ID: > I've included my console output below - does anyone know what's going on? Unfortunately I don't know. It's been several years since we've done anything with "SIPClient" (or the "playSIP" application), but it might be informative to look at a *successful* protocol exchange (with the same account, username and password) from some other SIP client, so we can see if there's anything different about the "Proxy-Authorization:" header in a successful "INVITE". (I presume, of course, that your username (1001) and password (1234) are correct :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at simonmaddox.com Mon Sep 10 03:33:25 2012 From: simon at simonmaddox.com (Simon Maddox) Date: Mon, 10 Sep 2012 11:33:25 +0100 Subject: [Live-devel] playSIP Authentication Error In-Reply-To: References: <98CC3B74684846188B7D30EE540172D2@simonmaddox.com> Message-ID: <3D398F68A15B471098F1DACA48CDB241@simonmaddox.com> > (I presume, of course, that your username (1001) and password (1234) are correct :-) Yes :) I've tried them in a standalone SIP client (pjsua, Telephone for Mac), and can REGISTER and INVITE successfully. > look at a *successful* protocol exchange (with the same account, username and password) from some other SIP client, so we can see if there's anything different about the "Proxy-Authorization:" header in a successful "INVITE" So, it looks like SIPClient doesn't fully implement the RFC 2617 spec. Basically, if "qop=" is sent in the Proxy-Authenticate response, you need to send a "cnonce" and "nc" value back as well. On top of that, SIPClient is sending the From: header as "user at my-ip", whereas it *should* be sending "user at sip-host". I've made both of these changes, but now I'm getting a 403 at the end of the process rather than a second 407. Guess there's something a bit more subtle going on - will report back if I find anything. Cheers, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From neilpep at gmail.com Mon Sep 10 03:28:21 2012 From: neilpep at gmail.com (Neil Pepper) Date: Mon, 10 Sep 2012 11:28:21 +0100 Subject: [Live-devel] F9F351CF-AE7C-4087-8698-7B4CFB6581B9@live555.com Message-ID: Hi Ross, not exactly sure how to reply on a thread, hope this is right. (tried emailing the thread email it just bounced) Thanks very much for your help, the light is dawning now ;-) slowly "so that *it* does the rendering (or calls a decoder library to do the rendering)" So I can assume the frame arrives encoded in H264 format and i need a 3rd party decoder like ffmpeg to decode it ? and there is no actual way to decode a H264 stream using live555 to a bitmap I can render to the screen ? Actually this was the first thing i looked at, then i saw the H264VideoRTPSink class and assumed it was decoder class as it inherited from MediaSink same as DummySink and when I drove down my blind alley. If i need to decode it using ffmpeg is there anyway to get resolution of video i can feed into the decoder or do i need to hard code this ? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 05:09:06 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 05:09:06 -0700 Subject: [Live-devel] Rendering a frame from H264 In-Reply-To: References: Message-ID: <0B7BBD08-58C2-4041-B08E-353BD49CC743@live555.com> [Somehow your "Subject:" line got fixed up; I fixed it for you - this time] > So I can assume the frame arrives encoded in H264 format and i need a 3rd party decoder like ffmpeg to decode it ? and there is no actual way to decode a H264 stream using live555 to a bitmap I can render to the screen ? That's correct. The "LIVE555 Streaming Media" software includes no codec (audio/video encoding or decoding) software. > If i need to decode it using ffmpeg is there anyway to get resolution of video i can feed into the decoder or do i need to hard code this ? I don't know (it depends on how "ffmpeg" works, which is outside the topic of this mailing list). But I suspect that just feeding the SPS and PPS NAL units (that I described in my previous email) to ffmpeg at the start will be sufficient. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruno.Marchand at averna.com Mon Sep 10 06:24:31 2012 From: Bruno.Marchand at averna.com (Bruno Marchand) Date: Mon, 10 Sep 2012 09:24:31 -0400 Subject: [Live-devel] RTP timestamp issue after RTCP synchronization In-Reply-To: <6A656F06-E78E-45BA-8653-82F4D65BF782@live555.com> References: <6A656F06-E78E-45BA-8653-82F4D65BF782@live555.com> Message-ID: Hi! In my previous post, I forgot to mention that I could get it to work by "cheating" a little bit on the RTP clocks. If I replace the 16000Hz clock of the mpeg stream by 90000, the same as h264, the two streams sync in the same range and play properly. I saw some VLC whining in the logs though. Could it be an overflow somewhere in the timestamps calculations? I'm pretty sure changing the clock isn't the solution but maybe it can give a clue on where the issue lies. If it can help, I'm compiling my module for Windows x64 and I can observe the issue on a Linux 32bits box too. For RTCP-based a/v synchronization to work properly for streams that are sent by the LIVE555 RTSP server implementation, two things have to be true: 1/ The presentation times for each frame have to be accurate (obviously), and 2/ The presentation times have to be aligned with 'wall-clock' time - i.e., times that would be generated by calling "gettimeofday()". At first I assumed the timestamps were right because they come out of the live library and my algorithm waits for the RTCP synchronisation to occur before feeding the streams into the rtsp server. After investigating this second point, I found an issue with my timestamps. My camera's date is somewhere in 2003 making synchronized timestamps way back in the past. If I correct the camera's date and time it fixes the issue I observed making my module and the proxy server working. This raises a new question: Is it possible to overcome the case where the sender has an incorrect date and time? For now I can fix the camera's date and time but I can't take this for granted when the system will be released. (Out of curiosity, does VLC play the stream OK (i.e., without any a/v sync problems) if you try playing it directly from the network camera (i.e., not through a proxy)?) Yes, the streams are played properly when vlc connects directly to the camera, even when the camera streams from the past. Thanks again for your support, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 06:36:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 06:36:51 -0700 Subject: [Live-devel] RTP timestamp issue after RTCP synchronization In-Reply-To: References: <6A656F06-E78E-45BA-8653-82F4D65BF782@live555.com> Message-ID: > I?m pretty sure changing the clock isn?t the solution but maybe it can give a clue on where the issue lies. Don't worry; I know where the issue lies (it's a bug/deficiency in the LIVE555 RTSP proxying code; see below). > After investigating this second point, I found an issue with my timestamps. My camera?s date is somewhere in 2003 making synchronized timestamps way back in the past. If I correct the camera?s date and time it fixes the issue I observed making my module and the proxy server working. This raises a new question: Is it possible to overcome the case where the sender has an incorrect date and time? Note that the sender's date and time are not really 'incorrect'. It's perfectly OK for them to be way in the past - or way in the future - as long as the audio and video timestamps are synchronized between themselves. However, there is a bug in our RTSP proxying code that prevents our proxy server from *sending* correct RTP timestamps (and correct RTCP "SR" packets) in this case. > For now I can fix the camera?s date and time but I can?t take this for granted when the system will be released. Yes - I'll need to fix the bug in the LIVE555 code. Stay tuned... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at Honeywell.com Mon Sep 10 08:01:28 2012 From: Giridhara.Kalkere at Honeywell.com (Kalkere, Giridhara(IE10)) Date: Mon, 10 Sep 2012 15:01:28 +0000 Subject: [Live-devel] testMPEG2TransportReceiver source code. Message-ID: <955512E27CA4E9478883ACDCA9CA40C616A458@IE1AEX3007.global.ds.honeywell.com> Hello All, I am using the livemedia for our project evaluations. I want to use the transport streams. I am Looking for the test program. But my base livemedia dir doesn't have this program. >From where I can download this source code? I have IP Cameras rtsp and MPEG/H264 supported. I want to connect to that camera over RSTP and receive the streams (raw MPEG4/H264) and store it in .ts format. I appreciate if some can help me to show me how this can be done. Thanks and Regards, Giri -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at Honeywell.com Mon Sep 10 08:02:45 2012 From: Giridhara.Kalkere at Honeywell.com (Kalkere, Giridhara(IE10)) Date: Mon, 10 Sep 2012 15:02:45 +0000 Subject: [Live-devel] testMPEG2TransportReceiver source code Message-ID: <955512E27CA4E9478883ACDCA9CA40C616A463@IE1AEX3007.global.ds.honeywell.com> Hello All, I am using the livemedia for our project evaluations. I want to use the transport streams. I am Looking for the test program. But my base livemedia dir doesn't have this program. >From where I can download this source code? I have IP Cameras rtsp and MPEG/H264 supported. I want to connect to that camera over RSTP and receive the streams (raw MPEG4/H264) and store it in .ts format. I appreciate if some can help me to show me how this can be done. Thanks and Regards, Giri -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at Honeywell.com Mon Sep 10 08:03:34 2012 From: Giridhara.Kalkere at Honeywell.com (Kalkere, Giridhara(IE10)) Date: Mon, 10 Sep 2012 15:03:34 +0000 Subject: [Live-devel] testMPEG2TransportReceiver source code Message-ID: <955512E27CA4E9478883ACDCA9CA40C616A46C@IE1AEX3007.global.ds.honeywell.com> Hello All, I am using the livemedia for our project evaluations. I want to use the transport streams. I am Looking for the test program. But my base livemedia dir doesn't have this program. >From where I can download this source code? I have IP Cameras rtsp and MPEG/H264 supported. I want to connect to that camera over RSTP and receive the streams (raw MPEG4/H264) and store it in .ts format. I appreciate if some can help me to show me how this can be done. Thanks and Regards, Giri -------------- next part -------------- An HTML attachment was scrubbed... URL: From ohsiao at miovision.com Mon Sep 10 09:04:58 2012 From: ohsiao at miovision.com (Ofelia Hsiao) Date: Mon, 10 Sep 2012 12:04:58 -0400 Subject: [Live-devel] Faking SDP Support using live555MediaServer Message-ID: Hello everyone, I'm trying to do the following: Using the live555MediaServer, return a specified video when client requests an url ending with .sdp. I think what I need to do is first, generate an sdp file from the video (which is in h264). However, I am not sure what tool is available to do that. I tried saving the file using VLC to of extension .sdp, but I don't think that's what I am looking for. I've read through many sdp threads in the mailing list and I don't think any of them answer this question. Sorry for such a newbie question. Thanks, Ofelia -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 11:13:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 11:13:33 -0700 Subject: [Live-devel] testMPEG2TransportReceiver source code In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C616A46C@IE1AEX3007.global.ds.honeywell.com> References: <955512E27CA4E9478883ACDCA9CA40C616A46C@IE1AEX3007.global.ds.honeywell.com> Message-ID: First, please DO NOT send the same message to the mailing list multiple times! Because of your rudeness, all future postings from you will be moderated. > I am using the livemedia for our project evaluations. I want to use the transport streams. I am Looking for the test program. But my base livemedia dir doesn?t have this program. That's because it's in the "testProgs" directory. See http://www.live555.com/liveMedia/#testProgs > I have IP Cameras rtsp and MPEG/H264 supported. I want to connect to that camera over RSTP and receive the streams (raw MPEG4/H264) and store it in .ts format. OK, but you won't use the "testMPEG2TransportReceiver" demo application for that. (I'll let you (try to) figure out what code you really need to use...) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 13:55:08 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 13:55:08 -0700 Subject: [Live-devel] Faking SDP Support using live555MediaServer In-Reply-To: References: Message-ID: <77ACAA32-7852-40DF-AC4B-A63A93110248@live555.com> > Using the live555MediaServer, return a specified video when client requests an url ending with .sdp. > > I think what I need to do is first, generate an sdp file from the video No. Server developers never work directly with SDP; instead, our server software automatically generates SDP descriptions (in response to RTSP "DESCRIBE" commands). Instead, all you need is the video source. > (which is in h264) If you have a H.264 Elementary Stream video file, then the easiest way to stream this is to rename it to have a ".264" filename suffix, and use the "LIVE555 Media Server" to stream it. If, however, you have a H.264 Elementary Stream video file that you *don't* want to rename it to have a ".264" filename suffix, then you can still stream it, but not using the "LIVE555 Media Server". Instead, you can build your own server - perhaps using the "testOnDemandRTSPServer" demo application as a model. (See "testProgs/testOnDemandRTSPServer.cpp", lines 89-101.) If, however, your H.264 video comes from a live source (e.g., from an encoder), rather than from a file, then you can still use "testOnDemandRTSPServer" as a model, but you have some additional programming to do. See the FAQ. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Sun Sep 9 19:52:48 2012 From: kingaceck at 163.com (kingaceck) Date: Mon, 10 Sep 2012 10:52:48 +0800 Subject: [Live-devel] A Problem of streaming MP4 file Message-ID: <201209101052470461120@163.com> Dear live dev team: (1) I have extended the live555 to support mp4 file.But when playing ,the vlc has no process bar and the total time's indicator(it's 00:00 at the lower right corner of vlc). I can't jump to another point to play in the vlc process bar area.what's the reason of this? (2) when playing,at the first 10 seconds there are many mosaic on the picture. what can I do to fix this problem? please help me.Thank you very much. 2012-09-10 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexrisb77 at hotmail.com Mon Sep 10 00:06:52 2012 From: alexrisb77 at hotmail.com (Alexander Risb) Date: Mon, 10 Sep 2012 09:06:52 +0200 Subject: [Live-devel] how to apply filters in rtsp live source In-Reply-To: References: Message-ID: Hi everyone, I'm using RTSP Proxy Server with no problems and I'm trying to apply filters in order to change from h264 format into some other. I have seen it's possible by using two files: input and output ones. But I haven't seen anything in order to apply this filters by using a the rtsp address given by the server directly without store the data in a file. I was wondered how I can do this. I appreciate any clue about it. Thanks a lot. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Mon Sep 10 16:51:34 2012 From: warren at etr-usa.com (Warren Young) Date: Mon, 10 Sep 2012 17:51:34 -0600 Subject: [Live-devel] H.264 in MPEG-2 TS streams roughly at the start In-Reply-To: <2FD4949D-3D7F-48E7-AB80-97701C3F42C4@live555.com> References: <5049A5B4.1090300@etr-usa.com> <2FD4949D-3D7F-48E7-AB80-97701C3F42C4@live555.com> Message-ID: <504E7D06.5030804@etr-usa.com> On 9/7/2012 10:13 PM, Ross Finlayson wrote: >> We've been unable to create files that stream as >> smoothly as our old MPEG-2 files. > > Our code has trouble streaming MPEG Transport Stream files that are > extremely VBR (variable bit rate), which is what I suspect your file is. Yes, that's right. It averages 8 Mbit/s, but it has peaks in the 20 Mbit/s range, and falls well below the average at times. Do you have any ffmpeg recipes for reducing variability? I ask because it seems to treat parameters like -maxrate the same way people treat speed limits. :) That is, are there known ways to tell it, "No really, I'm not kidding, max means max."? I'm not against using another encoder. We have several. It's just that most of the TS-capable ones we have are inflexible. They assume you're using some common hardware profile like ATSC, AVCHD, or BluRay. They either won't let you tune overall bit rate, or when you try, they create broken streams. > Down the road, a better solution might be to provide an alternative > implementation of the "MPEG2TransportStreamFramer" class that 'reads > ahead'...less efficient That wouldn't bother us at all. Our servers have gigs of RAM in them these days, and they are only being asked to serve dozens of streams maximum. If each took a few tens of MB so the server would have a big enough window to examine the stream before sending it out, it wouldn't be a problem. You can call it TAKE_LOTS_O_RAM_TO_PREBUFFER_THE_STREAM compile time parameter. > Another possibility would be store packet durations in the 'index file' > (that gets used when performing 'trick play' operations on Transport > Stream files. The disadvantage of this, however, is that it would work > only for prerecorded files, not 'live' input streams (e.g., from an > encoder). It would also require an incompatible change to the index > file format. I'm surprised you can't get what you need from the index file already. Doesn't it tell you whee all the I frames are in the file? If you take a guess at the GOP length, you can infer frame rate. It would be better if the file header included the observed average GOP length instead, of course. Then again, if the indexer were to do that, it could simply record the observed average bit rate, and its variability. That would help the RTSP server decide on an optimal buffer size. Instead of guessing something like "24 MB" it could say "(avg_bit_rate + max_variability) * seconds_of_buffer / 8" to get the buffer size in bytes necessary to hold that many seconds of video. From what we're seeing with this stream, it seems you need to prebuffer 30 seconds or so, before the current implementation can get a handle on overall bit rate. Using the 8 Mbit/s = 1 MB/second rule of thumb again, that means 30 MB. In 1 GB of RAM, that lets you stream 34 streams, plenty for us. From gunslingor at gmail.com Mon Sep 10 10:27:33 2012 From: gunslingor at gmail.com (WADE POLK) Date: Mon, 10 Sep 2012 13:27:33 -0400 Subject: [Live-devel] Live555 vs icecast In-Reply-To: References: Message-ID: What's the differences, benefits and disadvantages of each? How does it compare to paid versions like helix? Being a computer engineer, how long will it take me to master either so that I can integrate it into my existing website in an on demand YouTube type fashion. wade polk -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 19:45:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 19:45:03 -0700 Subject: [Live-devel] A Problem of streaming MP4 file In-Reply-To: <201209101052470461120@163.com> References: <201209101052470461120@163.com> Message-ID: <8D6CD378-0F19-4775-93D8-B3F499B66259@live555.com> > I have extended the live555 to support mp4 file.But when playing ,the vlc has no process bar and the total time's indicator(it's 00:00 at the lower right corner of vlc). I can't jump to another point to play in the vlc process bar area.what's the reason of this? If you want to support 'seeking' within your file, you need to reimplement the following two virtual functions of your new "ServerMediaSubsession" subclass(es): virtual float duration() const; You'll need to redefine this to return the track's duration in seconds (i.e., some value > 0.0) virtual void seekStream(unsigned clientSessionId, void* streamToken, double& seekNPT, double streamDuration, u_int64_t& numBytes); This is the function that will do the seeking. > > (2) > when playing,at the first 10 seconds there are many mosaic on the picture. what can I do to fix this problem? This is likely due to unusually large video frame sizes - i.e., too large for VLC's buffer. VLC automatically compensates for this when it sees it, by increasing its buffer size, but it can't do anything about the first too-large video frame (that got truncated). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 19:52:35 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 19:52:35 -0700 Subject: [Live-devel] A Problem of streaming MP4 file In-Reply-To: <8D6CD378-0F19-4775-93D8-B3F499B66259@live555.com> References: <201209101052470461120@163.com> <8D6CD378-0F19-4775-93D8-B3F499B66259@live555.com> Message-ID: <4CD4DDE5-94F6-43FF-88F0-6DCB5755D4AC@live555.com> > virtual void seekStream(unsigned clientSessionId, void* streamToken, double& seekNPT, double streamDuration, u_int64_t& numBytes); > This is the function that will do the seeking. A correction: The virtual function to redefine here (assuming that you've defined your own subclass of "OnDemandServerMediaSubsession" is: virtual void seekStreamSource(FramedSource* inputSource, double& seekNPT, double streamDuration, u_int64_t& numBytes); This is the function that will do the seeking. Note that there are several existing examples in the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 19:54:16 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 19:54:16 -0700 Subject: [Live-devel] A Problem of streaming MP4 file In-Reply-To: <8D6CD378-0F19-4775-93D8-B3F499B66259@live555.com> References: <201209101052470461120@163.com> <8D6CD378-0F19-4775-93D8-B3F499B66259@live555.com> Message-ID: <14EADE30-137E-47B3-AEBD-019CF3A6D8C2@live555.com> See also http://www.live555.com/liveMedia/faq.html#trick-mode Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From reply2010 at yeah.net Mon Sep 10 19:42:34 2012 From: reply2010 at yeah.net (reply2010) Date: Tue, 11 Sep 2012 10:42:34 +0800 (CST) Subject: [Live-devel] testOnDemandRTSPServer for pipeline Message-ID: <2afd8a4a.e85.139b334f161.Coremail.reply2010@yeah.net> hi,everyone i replace video file with pipeline for testOnDemandRTSPServer.cpp,but i find i could not play in rtsp client.However i could play in testH264VideoStreamer.cpp by the same way. i research code in two cpp file.i find startplaying code in two cpp file are similar,that is H264VideoRTPSink->startplaying at last.but in fact i could see video in rtsp client if i use testH264VideoStreamer.cpp,and could not see anything if i use testOnDemandRTSPServer.cpp. I want to play pipeline in testOnDemandRTSPServer,could any expert give me any light.why i could play and how to revise code in testOnDemandRTSPServer.cpp. any comment are welcome.thanks a lot. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at Honeywell.com Mon Sep 10 19:51:25 2012 From: Giridhara.Kalkere at Honeywell.com (Kalkere, Giridhara(IE10)) Date: Tue, 11 Sep 2012 02:51:25 +0000 Subject: [Live-devel] testMPEG2TransportReceiver source code In-Reply-To: References: <955512E27CA4E9478883ACDCA9CA40C616A46C@IE1AEX3007.global.ds.honeywell.com> Message-ID: <955512E27CA4E9478883ACDCA9CA40C616A57B@IE1AEX3007.global.ds.honeywell.com> Dear Ross, First of all I am really sorry for the multiple emails on the same topic. I had some problem with my outlook, that caused this problem. Coming to the point. I mean I didn't find those source files in the testProgs directory also. I figured out for my requirement I need to use the MPEG2TransportStreamFramer.cpp is that correct..? I will rephrase my requirement 1. I have IP Camera 2. I will the rtsp client to connect to it. 3. I start getting the frames (raw MPEG/H264) from the camera 4. I want construct a small chunks 1sec/2sec clips in .ts format. Please let me know how can I do this? Thanks and Regards, Giri From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, September 10, 2012 11:44 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testMPEG2TransportReceiver source code First, please DO NOT send the same message to the mailing list multiple times! Because of your rudeness, all future postings from you will be moderated. I am using the livemedia for our project evaluations. I want to use the transport streams. I am Looking for the test program. But my base livemedia dir doesn't have this program. That's because it's in the "testProgs" directory. See http://www.live555.com/liveMedia/#testProgs I have IP Cameras rtsp and MPEG/H264 supported. I want to connect to that camera over RSTP and receive the streams (raw MPEG4/H264) and store it in .ts format. OK, but you won't use the "testMPEG2TransportReceiver" demo application for that. (I'll let you (try to) figure out what code you really need to use...) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 21:43:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 21:43:47 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <504004D90200004D0007257E@pta-emo.csir.co.za> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> Message-ID: FYI, I've now installed a new version (2012.09.11) of the "LIVE555 Streaming Media" code that fixes the problem with clients occasionally sending RTCP "RR" packets 'early' (when streaming RTP/RTCP-over-TCP). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 10 22:03:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2012 22:03:20 -0700 Subject: [Live-devel] testMPEG2TransportReceiver source code In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C616A57B@IE1AEX3007.global.ds.honeywell.com> References: <955512E27CA4E9478883ACDCA9CA40C616A46C@IE1AEX3007.global.ds.honeywell.com> <955512E27CA4E9478883ACDCA9CA40C616A57B@IE1AEX3007.global.ds.honeywell.com> Message-ID: > I figured out for my requirement I need to use the MPEG2TransportStreamFramer.cpp is that correct..? No. > I will rephrase my requirement > > 1. I have IP Camera > 2. I will the rtsp client to connect to it. > 3. I start getting the frames (raw MPEG/H264) from the camera > 4. I want construct a small chunks 1sec/2sec clips in .ts format. > > Please let me know how can I do this? You want to feed your RTSP client's output (i.e., a sequence of video frames) into a "MPEG2TransportStreamFromESSource" object, and then feed this into a "FileSink" object. I suggest using the "testRTSPClient" code ("testProgs/testRTSPClient.cpp") as a model. At line 272, use a "FileSink" instead of a "DummySink". Before line 282, create a "MPEG2TransportStreamFromESSource" object, and then call "addNewVideoSource()", taking "scs.subsession->readSource()" as the "inputSource" parameter. Then call "scs.subsession->sink->startPlaying(") on your "MPEG2TransportStreamFromESSource" object (instead of on "scs.subsession->readSource()" as the code currently does). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvyagintsev at atlantis.ru Tue Sep 11 00:09:09 2012 From: zvyagintsev at atlantis.ru (=?koi8-r?B?+tfRx8nOw8XXIOHO1M/O?=) Date: Tue, 11 Sep 2012 11:09:09 +0400 Subject: [Live-devel] All client termination Message-ID: <00e701cd8fec$56f9d5c0$04ed8140$@ru> Hello. I am looking for safe code to terminate all active RTSPClient (and their connections) without stopping main Live555 loop. Right now Live555 loop run in separate thread. The clean up function can be called from the another thread and looks like this: void RTSPSession::cleanup() { HashTable const& objects = MediaLookupTable::ourMedia(*m_pliveenvironment)->getTable(); HashTable::Iterator* piterator = HashTable::Iterator::create(objects); MediaSession* pmediasession; vector clients; char const* key; while ( (pmediasession = (MediaSession*)piterator->next(key)) != NULL ) if (pmediasession->isRTSPClient()) clients.push_back(pmediasession); delete piterator; for_each(clients.begin(), clients.end(), bind1st(mem_fun(&RTSPSession::delete_client), this)); } void RTSPSession::delete_client(MediaSession* medium) { ((myRTSPClient*)medium)->shutdown(); } void myRTSPClient::shutdown() { MediaSubsession* psubsession; unsigned int total = 0; if (m_pmediasession) { MediaSubsessionIterator iterator(*m_pmediasession); while((psubsession = iterator.next()) != 0) total += shutdown(psubsession); if (total) sendTeardownCommand(*m_pmediasession, 0); } Medium::close(this); } ... virtual myRTSPClient::~myRTSPClient() { ... if (m_pmediasession) Medium::close(m_pmediasession); ... } But i am not sure - maybe the safest and more easiest way (without direct interaction with underlying hashtable) exist to do forcibly disconnection and cleaning up of all existed clients? ps Again, I don't want to stop Live555 loop so it is possible the data can arrive at any moment so I also need to guard this and prevent any client code if cleanup procedure is started. WBR, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 11 00:29:42 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2012 00:29:42 -0700 Subject: [Live-devel] All client termination In-Reply-To: <00e701cd8fec$56f9d5c0$04ed8140$@ru> References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> Message-ID: <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> > Right now Live555 loop run in separate thread. The clean up function can be called from the another thread No! You cannot safely do this! Read the FAQ (that you were asked to do before posting to this mailing list)! Apart from "triggerEvent()" (see below), all calls to LIVE555 code *must* be done within the LIVE555 thread - e.g., from a LIVE555 event handler. For an illustration of how to shutdown (and reclaim) a "RTSPClient" object - and all of the objects that it uses - see the function "shutdownStream()" in "testProgs/testRTSPClient.cpp". Now, you may wish to signal this shutdown/reclaim mechanism from an external thread - i.e., from a thread other than one that's running the LIVE555 event loop, for example, a GUI. To do this, use the "event trigger" mechanism (see the FAQ and "UsageEnvironment/include/UsageEnvironment.hh"). Note that the "triggerEvent()" function is the *only* LIVE555 function that can be called from an external thread. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvyagintsev at atlantis.ru Tue Sep 11 01:01:44 2012 From: zvyagintsev at atlantis.ru (=?utf-8?b?0JfQstGP0LPQuNC90YbQtdCy?= =?utf-8?b?0JDQvdGC0L7QvQ==?=) Date: Tue, 11 Sep 2012 08:01:44 +0000 (UTC) Subject: [Live-devel] All client termination References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> Message-ID: > No! ?You cannot safely do this! ?Read the FAQ (that you were asked to do before posting to this mailing list)! > > Apart from "triggerEvent()" (see below), all calls to LIVE555 code *must* be done within the LIVE555 thread - e.g., from a LIVE555 event handler. > > Now, you may wish to signal this shutdown/reclaim mechanism from an external thread - i.e., from a thread other than one that's running the LIVE555 event loop, for example, a GUI. ?To do this, use the "event trigger" mechanism (see the FAQ and "UsageEnvironment/include/UsageEnvironment.hh"). ?Note that the "triggerEvent()" function is the *only* LIVE555 function that can be called from an external thread. > Thanks, ill do this. Is it safe to do the same (code posted above) from "event trigger" - access to hashtable and shutdown all the clients? From finlayson at live555.com Tue Sep 11 01:06:18 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2012 01:06:18 -0700 Subject: [Live-devel] All client termination In-Reply-To: References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> Message-ID: <66702B30-D537-40B3-9D14-1C22A73B0AA1@live555.com> > Thanks, ill do this. > Is it safe to do the same (code posted above) from "event trigger" - access to > hashtable and shutdown all the clients? I didn't have time to look at your code in detail. However - as I noted in my previous message - the function "shutdownStream()" in "testProgs/testRTSPClient.cpp" illustrates how to shut down each "RTSPClient" object. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Tue Sep 11 05:17:33 2012 From: jshanab at smartwire.com (Jeff Shanab) Date: Tue, 11 Sep 2012 12:17:33 +0000 Subject: [Live-devel] Stuck in singlestep Message-ID: <615FD77639372542BF647F5EBAA2DBC225217791@IL-BOL-EXCH01.smartwire.com> I have a problem with pulling RTSP streams that needs to be reliable. If the stream stops I have a watchdog that times out after 5 seconds and changes my watch variable so the event loop in basic task scheduler will exit. The problem is in one edge case, I have debugged found that the flag is never read because I am stuck in singlestep(). So it looks like Select found data but the subsequent readfrom never returns. This is on our favorite toy OS, Windows. Is there a way I can configure the socket for a timeout so it will return when there is no data. My live 555 is a few months old. (I will check the version and any bug repair list when I am back in the network) -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 11 08:13:58 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2012 08:13:58 -0700 Subject: [Live-devel] Stuck in singlestep In-Reply-To: <615FD77639372542BF647F5EBAA2DBC225217791@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC225217791@IL-BOL-EXCH01.smartwire.com> Message-ID: <7226F47F-B3C7-40CF-B137-B49601E5306F@live555.com> > I have a problem with pulling RTSP streams that needs to be reliable. If the stream stops I have a watchdog that times out after 5 seconds and changes my watch variable so the event loop in basic task scheduler will exit. > > The problem is in one edge case, I have debugged found that the flag is never read because I am stuck in singlestep(). So it looks like Select found data but the subsequent readfrom never returns. Rather than trying to figure out a workaround to a problem that you don't fully understand, I suggest first trying to understand what the problem actually is, and what's causing it. Saying that you're "stuck in SingleStep()" isn't really meaningful, because - in LIVE555-based applications - *everything* runs within a call to "SingleStep()". And these days, the call to "select()" within the "BasicTaskScheduler" event loop can never block indefinitely, because of the "maxSchedulerGranularity" parameter. And it seems unlikely that "recvfrom()" could be blocking, because the sockets it reads from are all non-blocking. > My live 555 is a few months old Everyone should upgrade to the latest version of the software before posting to the mailing list. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Tue Sep 11 09:16:23 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Tue, 11 Sep 2012 16:16:23 +0000 Subject: [Live-devel] Proper function calls from other threads (was: RE: All client termination) In-Reply-To: <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> Message-ID: Right now Live555 loop run in separate thread. The clean up function can be called from the another thread No! You cannot safely do this! Read the FAQ (that you were asked to do before posting to this mailing list)! Apart from "triggerEvent()" (see below), all calls to LIVE555 code *must* be done within the LIVE555 thread - e.g., from a LIVE555 event handler. For an illustration of how to shutdown (and reclaim) a "RTSPClient" object - and all of the objects that it uses - see the function "shutdownStream()" in "testProgs/testRTSPClient.cpp". Now, you may wish to signal this shutdown/reclaim mechanism from an external thread - i.e., from a thread other than one that's running the LIVE555 event loop, for example, a GUI. To do this, use the "event trigger" mechanism (see the FAQ and "UsageEnvironment/include/UsageEnvironment.hh"). Note that the "triggerEvent()" function is the *only* LIVE555 function that can be called from an external thread. This is a mistake I first made, even after reading the FAQ. I somehow didn't think about that I was calling shutdown and issue PLAY-commands (seek) from my own thread (since it usually works fine). Looking at the example code I however thought it was safe to schedule tasks. After reading your response above I'd like to verify that what I do is correct. My question is... I'm not calling triggerEvent() directly, but instead scheduling tasks using the taskScheduler. The code example below is called from an external thread. Is that ok, and the proper way to do it? void StopStream(OurRTSPClient *rtspClient) { if (rtspClient) { UsageEnvironment& env = rtspClient->envir(); env.taskScheduler().scheduleDelayedTask(TASK_FUNCTION_CALL_DELAY_MS, (TaskFunc*)StopStreamTask, rtspClient); } } /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Tue Sep 11 09:47:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2012 09:47:51 -0700 Subject: [Live-devel] Proper function calls from other threads (was: RE: All client termination) In-Reply-To: References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> Message-ID: <48DD8F44-16B3-440A-A505-FD24917772EC@live555.com> > The code example below is called from an external thread. Is that ok No - absolutely not!!! What you're trying to do - call "TaskScheduler::scheduleDelayedTask()" from an external thread - is extremely wrong! Look folks, how many times do I have to say this: A LIVE555 application runs as a single-thread of control (using an event loop, rather than threads, to provide concurrency). If you want to communicate with a LIVE555 application from an external thread (i.e., from a thread other than the one that runs the LIVE555 event loop), then there are only two proper ways to do this: 1/ By setting a global variable, or 2/ Using an 'event trigger' - i.e., by calling "TaskScheduler::triggerEvent()". Note that "triggerEvent()" is the ***only*** LIVE555 function that you may call from an external thread. This is all explained in the FAQ that you were all asked to read before posting to this mailing list!!! In your case, you would do something like the following: 1/ Within the LIVE555 thread (e.g., somewhere after you've created "rtspClient"), call EventTriggerId myStopStreamEvent = env.taskScheduler().createEventTrigger(StopStream); 2/ Later, from an external thread, you can call: env.taskScheduler().triggerEvent(myStopStreamEvent, rtspClient); and this will cause your "StopStream()" function to be called (with "rtspClient" as parameter) from the event loop - i.e., as a handled event. (Note: For this to work, "env", "myStopStreamEvent" and "rtspClient" need to be global variables, so that they are visible to the external thread. Note, though, that they are never *modified* by the external thread, only read by it.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Tue Sep 11 09:42:30 2012 From: jshanab at smartwire.com (Jeff Shanab) Date: Tue, 11 Sep 2012 16:42:30 +0000 Subject: [Live-devel] Stuck in singlestep In-Reply-To: <7226F47F-B3C7-40CF-B137-B49601E5306F@live555.com> References: <615FD77639372542BF647F5EBAA2DBC225217791@IL-BOL-EXCH01.smartwire.com> <7226F47F-B3C7-40CF-B137-B49601E5306F@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC225217857@IL-BOL-EXCH01.smartwire.com> I agree It seems unlikely that it would be stuck in recvfrom() following a successful select, but it does. I have proven this with debugging. I checked the windows docs and if the flags are not set correctly on socket creation, the default will block forever. I am looking for where this socket is created so I can follow it's lifetime. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 11 10:02:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2012 10:02:56 -0700 Subject: [Live-devel] Stuck in singlestep In-Reply-To: <615FD77639372542BF647F5EBAA2DBC225217857@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC225217791@IL-BOL-EXCH01.smartwire.com> <7226F47F-B3C7-40CF-B137-B49601E5306F@live555.com> <615FD77639372542BF647F5EBAA2DBC225217857@IL-BOL-EXCH01.smartwire.com> Message-ID: > I agree It seems unlikely that it would be stuck in recvfrom() following a successful select, but it does. Well, if the "makeSocketNonBlocking()" function ("groupsock/GroupsockHelper.cpp", line 171) - which is called for all RTP/RTCP and RTSP sockets - is not working for you, then you're going to have to figure out why. (Nobody else seems to be having this problem...) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Tue Sep 11 10:11:24 2012 From: warren at etr-usa.com (Warren Young) Date: Tue, 11 Sep 2012 11:11:24 -0600 Subject: [Live-devel] H.264 in MPEG-2 TS streams roughly at the start In-Reply-To: <504E7D06.5030804@etr-usa.com> References: <5049A5B4.1090300@etr-usa.com> <2FD4949D-3D7F-48E7-AB80-97701C3F42C4@live555.com> <504E7D06.5030804@etr-usa.com> Message-ID: <504F70BC.8020900@etr-usa.com> On 9/10/2012 5:51 PM, Warren Young wrote: > > If you take > a guess at the GOP length, you can infer frame rate. I meant bit rate, obviously. We've tried to get a CBR stream out of ffmpeg, just to prove to ourselves that stream variability is the problem. We haven't succeeded. Apparently ffmpeg is incapable of CBR with H.264, even when you set min = avg = max. That said, those settings did greatly reduce the variability. Here's the new stream: http://etr-usa.com/live555/h264-test-cbr.ts It shows the same stuttery playback with the stock build of the RTSP server. The bit rate range is now 5-10 Mbit/s over the majority of the play time, averaging 7.5 Mbit/s. (It was 2-16 Mbit/s!) We'll try to get a less variable file out of other encoders next. From nouri at soroush.net Tue Sep 11 13:54:33 2012 From: nouri at soroush.net (Mojtaba Nouri) Date: Wed, 12 Sep 2012 01:24:33 +0430 Subject: [Live-devel] H.264 in MPEG-2 TS streams roughly at the start In-Reply-To: <504F70BC.8020900@etr-usa.com> References: <5049A5B4.1090300@etr-usa.com> <2FD4949D-3D7F-48E7-AB80-97701C3F42C4@live555.com> <504E7D06.5030804@etr-usa.com> <504F70BC.8020900@etr-usa.com> Message-ID: Hi We had the same problem, and we solved it by creating cbr ts files stuffed with NULL packets. The following thread shows the ffmpeg command parameters to create h.264 cbr files: http://stackoverflow.com/questions/7125446/encoding-h-264-cbr-videos-with-ffmpeg Mojtaba Nouri Soroush HighTech Ltd. On Tue, Sep 11, 2012 at 9:41 PM, Warren Young wrote: > On 9/10/2012 5:51 PM, Warren Young wrote: > >> >> If you take >> a guess at the GOP length, you can infer frame rate. >> > > I meant bit rate, obviously. > > We've tried to get a CBR stream out of ffmpeg, just to prove to ourselves > that stream variability is the problem. We haven't succeeded. Apparently > ffmpeg is incapable of CBR with H.264, even when you set min = avg = max. > > That said, those settings did greatly reduce the variability. Here's the > new stream: > > http://etr-usa.com/live555/**h264-test-cbr.ts > > It shows the same stuttery playback with the stock build of the RTSP > server. The bit rate range is now 5-10 Mbit/s over the majority of the > play time, averaging 7.5 Mbit/s. (It was 2-16 Mbit/s!) > > We'll try to get a less variable file out of other encoders next. > > ______________________________**_________________ > 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 CERLANDS at arinc.com Tue Sep 11 15:06:02 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Tue, 11 Sep 2012 22:06:02 +0000 Subject: [Live-devel] Proper function calls from other threads (was: RE: All client termination) In-Reply-To: <48DD8F44-16B3-440A-A505-FD24917772EC@live555.com> References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> <48DD8F44-16B3-440A-A505-FD24917772EC@live555.com> Message-ID: The code example below is called from an external thread. Is that ok No - absolutely not!!! What you're trying to do - call "TaskScheduler::scheduleDelayedTask()" from an external thread - is extremely wrong! Look folks, how many times do I have to say this: A LIVE555 application runs as a single-thread of control (using an event loop, rather than threads, to provide concurrency). If you want to communicate with a LIVE555 application from an external thread (i.e., from a thread other than the one that runs the LIVE555 event loop), then there are only two proper ways to do this: 1/ By setting a global variable, or 2/ Using an 'event trigger' - i.e., by calling "TaskScheduler::triggerEvent()". Note that "triggerEvent()" is the ***only*** LIVE555 function that you may call from an external thread. This is all explained in the FAQ that you were all asked to read before posting to this mailing list!!! In your case, you would do something like the following: 1/ Within the LIVE555 thread (e.g., somewhere after you've created "rtspClient"), call EventTriggerId myStopStreamEvent = env.taskScheduler().createEventTrigger(StopStream); 2/ Later, from an external thread, you can call: env.taskScheduler().triggerEvent(myStopStreamEvent, rtspClient); and this will cause your "StopStream()" function to be called (with "rtspClient" as parameter) from the event loop - i.e., as a handled event. (Note: For this to work, "env", "myStopStreamEvent" and "rtspClient" need to be global variables, so that they are visible to the external thread. Note, though, that they are never *modified* by the external thread, only read by it.) Thanks a lot for taking the time to (again) clarify things. One last question on this, as I'm in the middle of reorganizing the code. Shouldn't it be safe to create the rtspClient object in another thread? I can't really see a problem with that as it only appears to assign variables. Since I was so wrong before, I want to verify though ;-) Besides just being curious and want to find out, it would also simplify things in the application I'm working on. The application creates clients dynamically and starts up without any active clients. Having to create the rtspClient objects using triggers would introduce additional callbacks and making passing arguments a bit more complex. This is now the "main startup code": void InitStreamEngine() { TaskScheduler* scheduler = BasicTaskScheduler::createNew(); usageEnvironment = BasicUsageEnvironment::createNew(*scheduler); myStartStreamEvent = usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)StartStreamE vent); myStopStreamEvent = usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)StopStreamEv ent); mySeekAbsoluteEvent = usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)SeekAbsolute Event); usageEnvironment->taskScheduler().doEventLoop(&eventLoopWatchVariable); } /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Tue Sep 11 15:36:09 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2012 15:36:09 -0700 Subject: [Live-devel] Proper function calls from other threads (was: RE: All client termination) In-Reply-To: References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> <48DD8F44-16B3-440A-A505-FD24917772EC@live555.com> Message-ID: <96CE4F3E-2D2C-4A3A-B47D-FAECE1C56D73@live555.com> > One last question on this, as I'm in the middle of reorganizing the code. > Shouldn't it be safe to create the rtspClient object in another thread? Once again, NO! "RTSPClient" objects - like all subclasses of class "Medium" - update shared data structures (stored within the "UsageEnvironment" object) when they are constructed. A single "UsageEnvironment" object MUST NOT be accessed from multiple threads (except that the "triggerEvent()" member function may be called from a non-LIVE555-event-loop thread). > Having to create the rtspClient objects using triggers would introduce additional callbacks and making passing arguments a bit more complex. Nonetheless, if you are creating these "RTSPClient" objects dynamically, then the creation of each of these objects has to be done as an 'event' - i.e., done from a handler function that's called from the LIVE555 thread. And the only way to signal this from an external thread is to call "triggerEvent()", or to use the 'watch variable' mechanism. > This is now the "main startup code": > > void InitStreamEngine() > { > TaskScheduler* scheduler = BasicTaskScheduler::createNew(); > usageEnvironment = BasicUsageEnvironment::createNew(*scheduler); > > myStartStreamEvent = usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)StartStreamEvent); > myStopStreamEvent = usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)StopStreamEvent); > mySeekAbsoluteEvent = usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)SeekAbsoluteEvent); > > usageEnvironment->taskScheduler().doEventLoop(&eventLoopWatchVariable); > } This looks fine. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at vincze.org Tue Sep 11 12:40:16 2012 From: tom at vincze.org (Tamas Vincze) Date: Tue, 11 Sep 2012 15:40:16 -0400 Subject: [Live-devel] [PATCH] make RTSP server librtsp compatible Message-ID: <504F93A0.70808@vincze.org> The attached patch enables MPlayer using librtsp to connect to the RTSP server. When running mplayer rtsp://10.10.4.10/ then it sends the OPTIONS URL like this: OPTIONS rtsp://10.10.4.10:554 RTSP/1.0 note there's no trailing slash after the port and the current code fails to parse it and sends back a Bad Request reply. Tamas -------------- next part -------------- A non-text attachment was scrubbed... Name: live-mplayer.patch Type: text/x-patch Size: 1988 bytes Desc: not available URL: From tom at vincze.org Tue Sep 11 13:03:04 2012 From: tom at vincze.org (Tamas Vincze) Date: Tue, 11 Sep 2012 16:03:04 -0400 Subject: [Live-devel] [PATCH] wis-streamer fixes to work with 3.x.x kernel Message-ID: <504F98F8.4060108@vincze.org> The attached patch enables wis-streamer to work with current 3.x.x kernels. - remove float_t because it's unused and conflicts with math.h - in the Makefile put libliveMedia.a to the first place, otherwise linking fails - make search for the audio device compatible with the current sysfs paths Tamas -------------- next part -------------- A non-text attachment was scrubbed... Name: wis-streamer.patch Type: text/x-patch Size: 2847 bytes Desc: not available URL: From finlayson at live555.com Tue Sep 11 17:07:29 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2012 17:07:29 -0700 Subject: [Live-devel] [PATCH] make RTSP server librtsp compatible In-Reply-To: <504F93A0.70808@vincze.org> References: <504F93A0.70808@vincze.org> Message-ID: <751F966B-D3B8-444B-862F-2770BDFA30EA@live555.com> Thanks (and special thanks for the detailed explanation in the comment that you included with the patch). I have just installed a new version (2012.09.12) of the "LIVE555 Streaming Media" code that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 11 17:19:39 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2012 17:19:39 -0700 Subject: [Live-devel] [PATCH] wis-streamer fixes to work with 3.x.x kernel In-Reply-To: <504F98F8.4060108@vincze.org> References: <504F98F8.4060108@vincze.org> Message-ID: <1F3EAC02-6FD6-4474-A9D6-8490807B7C13@live555.com> OK, thanks. Updated now. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Wed Sep 12 01:21:28 2012 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Wed, 12 Sep 2012 10:21:28 +0200 Subject: [Live-devel] RTPSource for mime "application/VND.ONVIF.METADATA" Message-ID: <24385_1347438109_5050461D_24385_13950_1_1BE8971B6CFF3A4F97AF4011882AA255015602760E10@THSONEA01CMS01P.one.grp> Hi Ross, I follow the documention in MediaSession.hh that explain how to support a specific payload to support mime "application/VND.ONVIF.METADATA". This works without problem, and doesnot did any modification of live555, then it's ok. However, the implmentation I didn't doesnot do anything, just creating a SimpleRTPSource, then I would like to know if it's possible to support this mime in some next live555 release ? Best Regards, Michel. [@@THALES GROUP RESTRICTED@@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 12 04:51:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Sep 2012 04:51:47 -0700 Subject: [Live-devel] RTPSource for mime "application/VND.ONVIF.METADATA" In-Reply-To: <24385_1347438109_5050461D_24385_13950_1_1BE8971B6CFF3A4F97AF4011882AA255015602760E10@THSONEA01CMS01P.one.grp> References: <24385_1347438109_5050461D_24385_13950_1_1BE8971B6CFF3A4F97AF4011882AA255015602760E10@THSONEA01CMS01P.one.grp> Message-ID: <5FEF0883-01F4-44DF-98AA-69BB2EA3E766@live555.com> > I follow the documention in MediaSession.hh that explain how to support a specific payload to support mime "application/VND.ONVIF.METADATA". > This works without problem, and doesnot did any modification of live555, then it's ok. > > However, the implmentation I didn't doesnot do anything, just creating a SimpleRTPSource FYI, if you're OK just receiving otherwise unknown RTP payload formats using a "SimpleRTPSource", then you don't need to do any subclassing to do this. Instead, just call "MediaSession::initiate()" with a "useSpecialRTPoffset" parameter of 0. This will tell the LIVE555 code to implement this (otherwise unknown) RTP payload format using a "SimpleRTPSource" - without the need to do any subclassing or adding any code of your own. > , then I would like to know if it's possible to support this mime in some next live555 release ? This RTP payload format is not defined in any IETF RFC, but - according to 'ONVIF' documents - it contains just XML text, without any special RTP headers, and therefore you should not need any special "RTPSource" subclass in order to receive it. "SimpleRTPSource" should be sufficient, and - as I noted above - you can get this automatically just by passing a "useSpecialRTPoffset" parameter of 0 to "MediaSession::initiate()". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 12 05:18:10 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Sep 2012 05:18:10 -0700 Subject: [Live-devel] RTPSource for mime "application/VND.ONVIF.METADATA" In-Reply-To: <5FEF0883-01F4-44DF-98AA-69BB2EA3E766@live555.com> References: <24385_1347438109_5050461D_24385_13950_1_1BE8971B6CFF3A4F97AF4011882AA255015602760E10@THSONEA01CMS01P.one.grp> <5FEF0883-01F4-44DF-98AA-69BB2EA3E766@live555.com> Message-ID: <2CE2CB61-8700-421B-8F8D-9DB7FF4D2965@live555.com> >> , then I would like to know if it's possible to support this mime in some next live555 release ? > > This RTP payload format is not defined in any IETF RFC, but - according to 'ONVIF' documents - it contains just XML text, without any special RTP headers, and therefore you should not need any special "RTPSource" subclass in order to receive it. "SimpleRTPSource" should be sufficient, and - as I noted above - you can get this automatically just by passing a "useSpecialRTPoffset" parameter of 0 to "MediaSession::initiate()". But having said that - I suppose it wouldn't hurt to add a special check for "VND.ONVIF.METADATA" at line 1321 of "MediaSession.cpp", so that you don't have to bother with the "useSpecialRTPOffset" parameter. So yes, I'll add this to the next source code release. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Wed Sep 12 04:15:31 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Wed, 12 Sep 2012 19:15:31 +0800 Subject: [Live-devel] Regarding combine audio and video in one session Message-ID: <000c01cd90d7$edad5320$c907f960$@126.com> I have one camera which can product audio and video. Now I can setup the rtsp server which supports audio and video in two sessions. But I don?t know how to build one rtsp server which support audio and video in one session. Like if user access rtsp://192.168.1.1/test, then he would get the audio and video. I saw the demo shows that if audio and video is stored in mkv, then it would work. But I don?t do it like this, so how should I do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From reply2010 at yeah.net Wed Sep 12 05:12:50 2012 From: reply2010 at yeah.net (reply2010) Date: Wed, 12 Sep 2012 20:12:50 +0800 (CST) Subject: [Live-devel] how to play rtsp://xxx.xxx.xxx.xxx:8554/filename.h264 Message-ID: <39ea3a93.759f.139ba656312.Coremail.reply2010@yeah.net> hi everyone i want to play any file in a directory by live555's.testOnDemandRTSPServer.however,there are many many files in this directory,and the count of files are increasing in this directory.i have to add many many H264VideoFileServerMediaSubsession in testOnDemandRTSPServer.cpp if i want to play any of them.anyone could tell me how to play any files if i don't add many many H264VideoFileServerMediaSubsession.i want to know if i could play rtsp stream by rtsp link including file name.such as rtsp://xxx.xxx.xxx.xxx:8554/filename.h264. any comment would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 12 06:08:49 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Sep 2012 06:08:49 -0700 Subject: [Live-devel] how to play rtsp://xxx.xxx.xxx.xxx:8554/filename.h264 In-Reply-To: <39ea3a93.759f.139ba656312.Coremail.reply2010@yeah.net> References: <39ea3a93.759f.139ba656312.Coremail.reply2010@yeah.net> Message-ID: <87A84A9D-D920-4DA2-B364-04A69B0EFD77@live555.com> > i want to play any file in a directory by live555's.testOnDemandRTSPServer.however,there are many many files in this directory,and the count of files are increasing in this directory.i have to add many many H264VideoFileServerMediaSubsession in testOnDemandRTSPServer.cpp if i want to play any of them.anyone could tell me how to play any files if i don't add many many H264VideoFileServerMediaSubsession. I suggest using the "LIVE555 Media Server" (see ), instead of "testOnDemandRTSPServer". The "LIVE555 Media Server" will automatically stream any (valid) file that's in its directory, without the programmer having to explicitly add a "ServerMediaSubsession". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 12 06:30:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Sep 2012 06:30:45 -0700 Subject: [Live-devel] Regarding combine audio and video in one session In-Reply-To: <000c01cd90d7$edad5320$c907f960$@126.com> References: <000c01cd90d7$edad5320$c907f960$@126.com> Message-ID: > I have one camera which can product audio and video. > Now I can setup the rtsp server which supports audio and video in two sessions. > But I don?t know how to build one rtsp server which support audio and video in one session. It's easy. Once you've created your "ServerMediaSession" object, you can then call "ServerMediaSession::addSubsession()" multiple times - once for each (audio or video) track (i.e., "ServerMediaSubsession") that you want to support within this stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at vincze.org Wed Sep 12 06:31:35 2012 From: tom at vincze.org (Tamas Vincze) Date: Wed, 12 Sep 2012 09:31:35 -0400 Subject: [Live-devel] [PATCH] make RTSP server librtsp compatible In-Reply-To: <751F966B-D3B8-444B-862F-2770BDFA30EA@live555.com> References: <504F93A0.70808@vincze.org> <751F966B-D3B8-444B-862F-2770BDFA30EA@live555.com> Message-ID: <50508EB7.3040000@vincze.org> Sure! I made a little mistake in the comment (the attached patch corrects it): k1 is actually equal to k in the first case, but it doesn't affect the code. Tamas > Thanks (and special thanks for the detailed explanation in the comment > that you included with the patch). > > I have just installed a new version (2012.09.12) of the "LIVE555 > Streaming Media" code that fixes this. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTSPCommon.cpp.patch Type: text/x-patch Size: 397 bytes Desc: not available URL: From reply2010 at yeah.net Wed Sep 12 06:46:04 2012 From: reply2010 at yeah.net (reply2010) Date: Wed, 12 Sep 2012 21:46:04 +0800 (CST) Subject: [Live-devel] how to play rtsp://xxx.xxx.xxx.xxx:8554/filename.h264 In-Reply-To: <87A84A9D-D920-4DA2-B364-04A69B0EFD77@live555.com> References: <39ea3a93.759f.139ba656312.Coremail.reply2010@yeah.net> <87A84A9D-D920-4DA2-B364-04A69B0EFD77@live555.com> Message-ID: <260f381.796f.139babac050.Coremail.reply2010@yeah.net> kind expert Ross Finlayson, thanks.I have test live555MediaServer.Good.But i find i could not trick play h264.Could live555MediaServer trick play h264 file?as i known,ts could trick play,i want to know if h264 could do it.thank you again. At 2012-09-12 21:08:49,"Ross Finlayson" wrote: i want to play any file in a directory by live555's.testOnDemandRTSPServer.however,there are many many files in this directory,and the count of files are increasing in this directory.i have to add many many H264VideoFileServerMediaSubsession in testOnDemandRTSPServer.cpp if i want to play any of them.anyone could tell me how to play any files if i don't add many many H264VideoFileServerMediaSubsession. I suggest using the "LIVE555 Media Server" (see ), instead of "testOnDemandRTSPServer". The "LIVE555 Media Server" will automatically stream any (valid) file that's in its directory, without the programmer having to explicitly add a "ServerMediaSubsession". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 12 06:59:07 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Sep 2012 06:59:07 -0700 Subject: [Live-devel] how to play rtsp://xxx.xxx.xxx.xxx:8554/filename.h264 In-Reply-To: <260f381.796f.139babac050.Coremail.reply2010@yeah.net> References: <39ea3a93.759f.139ba656312.Coremail.reply2010@yeah.net> <87A84A9D-D920-4DA2-B364-04A69B0EFD77@live555.com> <260f381.796f.139babac050.Coremail.reply2010@yeah.net> Message-ID: <3D7E664B-7701-4012-A27C-085E33280ADD@live555.com> > Could live555MediaServer trick play h264 file?as i known,ts could trick play,i want to know if h264 could do it. No it can't. The server supports 'trick play' only for certain kinds of media - but currently not H.264 elementary streams. See http://www.live555.com/liveMedia/faq.html#trick-mode Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Wed Sep 12 07:32:35 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Wed, 12 Sep 2012 14:32:35 +0000 Subject: [Live-devel] Proper function calls from other threads (was: RE: All client termination) In-Reply-To: <96CE4F3E-2D2C-4A3A-B47D-FAECE1C56D73@live555.com> References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> <48DD8F44-16B3-440A-A505-FD24917772EC@live555.com> <96CE4F3E-2D2C-4A3A-B47D-FAECE1C56D73@live555.com> Message-ID: One last question on this, as I'm in the middle of reorganizing the code. Shouldn't it be safe to create the rtspClient object in another thread? Once again, NO! "RTSPClient" objects - like all subclasses of class "Medium" - update shared data structures (stored within the "UsageEnvironment" object) when they are constructed. A single "UsageEnvironment" object MUST NOT be accessed from multiple threads (except that the "triggerEvent()" member function may be called from a non-LIVE555-event-loop thread). Got it. I'm happy that I asked... For a class that's created outside of liveMedia, it still seem safe to store temporary variables even though they can be accessed via the rtspClient object. I'm thinking of StreamClientState (as used in the testRTSPClient example). It is only part of OurRTSPClient, not RTSPClient. If I add a variable there that I know is only accessed in two places, it appears perfectly safe even if it will be written to from one thread and read from another. I can't think of any problems passing arguments that way. If anyone see any possible issue, please enlighten me what could potentially go wrong. In the example below, SeekAbsolute() will execute on a second thread, assigning scs.seekToAbsolutePosition, while SeekAbsoluteEvent() will be executed on the liveMedia thread reading the value. void SeekAbsolute(OurRTSPClient *rtspClient, char *seekTo) { if (rtspClient) { // Pass on the argument. StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs; strcpy_s(scs.seekToAbsolutePosition, sizeof(scs.seekToAbsolutePosition), seekTo); UsageEnvironment& env = rtspClient->envir(); env.taskScheduler().triggerEvent(mySeekAbsoluteEvent, rtspClient); } } void SeekAbsoluteEvent(OurRTSPClient *rtspClient) { StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs; rtspClient->sendPlayCommand(*scs.session, continueAfterPLAY, *scs.seekToAbsolutePosition); } /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Wed Sep 12 11:50:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Sep 2012 11:50:56 -0700 Subject: [Live-devel] Proper function calls from other threads (was: RE: All client termination) In-Reply-To: References: <00e701cd8fec$56f9d5c0$04ed8140$@ru> <3A4BC955-65D2-4AB2-933E-221AA3C81C22@live555.com> <48DD8F44-16B3-440A-A505-FD24917772EC@live555.com> <96CE4F3E-2D2C-4A3A-B47D-FAECE1C56D73@live555.com> Message-ID: <5DCFEE8B-4CA8-48AE-B82E-E37646A32122@live555.com> > In the example below, SeekAbsolute() will execute on a second thread, assigning scs.seekToAbsolutePosition [...] > void SeekAbsolute(OurRTSPClient *rtspClient, char *seekTo) > { > if (rtspClient) > { > // Pass on the argument. > StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs; > strcpy_s(scs.seekToAbsolutePosition, sizeof(scs.seekToAbsolutePosition), seekTo); > > UsageEnvironment& env = rtspClient->envir(); > env.taskScheduler().triggerEvent(mySeekAbsoluteEvent, rtspClient); > } > } Yes, this looks fine (provided, of course that nothing in the LIVE555 event loop thread also modifies "scs.seekToAbsolutePosition", or can delete "rtspClient" while "SeekAbsolute()" is being called). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From av1474 at comtv.ru Wed Sep 12 10:05:46 2012 From: av1474 at comtv.ru (malc) Date: Wed, 12 Sep 2012 21:05:46 +0400 (MSK) Subject: [Live-devel] H264VideoStreamFramer Message-ID: Hello, Few years back i've implemented a simple application which used live555 to connect to an IP camera, acquire video stream via RTSP/RTP and transmux video from H264ES to a MPEG2TS via libavformat, this setup worked. Now being made aware of H264VideoStreamFramer i decided to give it a try but am failing miserably. Basically, i'm doing this: framer = H264VideoStreamFramer::createNew (*env, subsession->readSource (), True/*includeStartCodeInOutput*/); MPEG2TransportStreamFromESSource* tsFrames = MPEG2TransportStreamFromESSource::createNew (*env); tsFrames->addNewVideoSource(framer, 5/*mpegVersion: H.264*/); MediaSink *sink = new SimpleFileDumperSink (*env); subsession->sink = sink; subsession->sink->startPlaying(*tsFrames, // *subsession->readSource (), subsessionAfterPlaying, subsession); So, in a nutshell, instead of feeding the SimpleFileDumperSink the *subsession->readSource, i'm attempting to feed it tsFrames which feds from the framer which feds from the RTP instead. What i'm getting is an empty output file and console filled with something like: MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (12443). 25905 bytes of trailing data will be dropped! o Timestamp on the copy of live555-latest.tar.gz is 2012-08-31 o The RTP server is live/mediaServer/live555MediaServer o The sample ES stream is http://samples.mplayerhq.hu/V-codecs/h264/src13_hrc7_525_420_2.264 o The sample code that fails is at http://boblycat.org/~malc/es2ts.cpp I'm not confident that what i'm doing is correct or proper way to achieve the desired goal, so any hints/suggestions will be greatly appreciated. -- mailto:av1474 at comtv.ru From finlayson at live555.com Wed Sep 12 13:25:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Sep 2012 13:25:54 -0700 Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: References: Message-ID: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> > framer = H264VideoStreamFramer::createNew > (*env, subsession->readSource (), True/*includeStartCodeInOutput*/); > > MPEG2TransportStreamFromESSource* tsFrames = > MPEG2TransportStreamFromESSource::createNew (*env); > tsFrames->addNewVideoSource(framer, 5/*mpegVersion: H.264*/); Your problem here is your use of "H264VideoStreamFramer". That class is intended to be used when reading from a *byte stream* that contains a sequence of H.264 NAL units - e.g., from a file. That's why it's used in the "testH264VideoToTransportStream" demo application, whose code you used as a model. Unfortunately, because you are using a RTSP/RTP client, the input source is *not* a byte stream. Instead, it is a sequence of discrete H.264 NAL units - one at a time. Because of this, the data from your RTSP/RTP stream - i.e., "subsession->readSource()" - should *not* be fed into a "H264VideoStreamFramer". Instead, *in principle*, you could just feed "subsession->readSource()" directly into your "MPEG2TransportStreamFromESSource" (via the "addNewVideoSource()" call). Unfortunately, however, there's a problem with this: The H.264 NAL units that come from the RTP source (i.e., from "subsession->readSource()") do not have a 4-byte 'start code' (i.e., 0x00 0x00 0x00 0x01) at the front, but that data that you feed into a "MPEG2TransportStreamFromESSource" needs to have these start codes. Therefore, you will need to write your own subclass of "FramedFilter" that adds a 4-byte 'start code' to each input frame, and use an instance of this class - instead of "H264VideoStreamFramer" - in front of "subsession->readSource()". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.coyne at gmeci.com Wed Sep 12 13:36:03 2012 From: patrick.coyne at gmeci.com (Patrick Coyne) Date: Wed, 12 Sep 2012 16:36:03 -0400 Subject: [Live-devel] cross Compiling for armlinux Message-ID: <5050F233.8040908@gmeci.com> Hello, I was trying to cross compile live555 for an armlinux processor using the ./genMakefiles armlinux and then run make but when it is trying to compile it can not find the file and I have looked everywhere I can online to find the cross compiler but I can not find it i have tried to use other ones but it says they are not compatible. Will live555 be able to work on devices like this is there a way to find arm-elf-gcc, or is there another cross compiler I can use. Patrick Coyne From chris at gotowti.com Wed Sep 12 14:19:17 2012 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Wed, 12 Sep 2012 14:19:17 -0700 Subject: [Live-devel] cross Compiling for armlinux In-Reply-To: <5050F233.8040908@gmeci.com> References: <5050F233.8040908@gmeci.com> Message-ID: <042701cd912c$44f778f0$cee66ad0$@com> Hi Patrick, I am cross-compiling LIVE555 libraries for ARM (TI DM36x platform). We have a config file that was generated in-house but it looks like it is based on config.armlinux. It basically just sets the CROSS_COMPILE variable to point at our Code Sourcery toolchain installation, sets the INCLUDES variable to the basic LIVE555 include directories and sets some additional compiler options. I am assuming you have documentation for your target device that explains how to set up the cross-compilation toolchain. Once you have that set up, you can point CROSS_COMPILE at it and see how far you get. Chris Richardson -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Patrick Coyne Sent: Wednesday, September 12, 2012 1:36 PM To: live-devel at ns.live555.com Subject: [Live-devel] cross Compiling for armlinux Hello, I was trying to cross compile live555 for an armlinux processor using the ./genMakefiles armlinux and then run make but when it is trying to compile it can not find the file and I have looked everywhere I can online to find the cross compiler but I can not find it i have tried to use other ones but it says they are not compatible. Will live555 be able to work on devices like this is there a way to find arm-elf-gcc, or is there another cross compiler I can use. Patrick Coyne _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From av1474 at comtv.ru Wed Sep 12 14:53:36 2012 From: av1474 at comtv.ru (malc) Date: Thu, 13 Sep 2012 01:53:36 +0400 (MSK) Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> References: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> Message-ID: On Wed, 12 Sep 2012, Ross Finlayson wrote: > > framer = H264VideoStreamFramer::createNew > > (*env, subsession->readSource (), True/*includeStartCodeInOutput*/); > > > > MPEG2TransportStreamFromESSource* tsFrames = > > MPEG2TransportStreamFromESSource::createNew (*env); > > tsFrames->addNewVideoSource(framer, 5/*mpegVersion: H.264*/); > > Your problem here is your use of "H264VideoStreamFramer". That > class is intended to be used when reading from a *byte stream* that > contains a sequence of H.264 NAL units - e.g., from a file. That's > why it's used in the "testH264VideoToTransportStream" demo > application, whose code you used as a model. > > Unfortunately, because you are using a RTSP/RTP client, the input > source is *not* a byte stream. Instead, it is a sequence of > discrete H.264 NAL units - one at a time. Because of this, the data > from your RTSP/RTP stream - i.e., "subsession->readSource()" - > should *not* be fed into a "H264VideoStreamFramer". > > Instead, *in principle*, you could just feed > "subsession->readSource()" directly into your > "MPEG2TransportStreamFromESSource" (via the "addNewVideoSource()" > call). Unfortunately, however, there's a problem with this: The > H.264 NAL units that come from the RTP source (i.e., from > "subsession->readSource()") do not have a 4-byte 'start code' (i.e., > 0x00 0x00 0x00 0x01) at the front, but that data that you feed into > a "MPEG2TransportStreamFromESSource" needs to have these start > codes. > > Therefore, you will need to write your own subclass of > "FramedFilter" that adds a 4-byte 'start code' to each input frame, > and use an instance of this class - instead of > "H264VideoStreamFramer" - in front of "subsession->readSource()". > That (adding {0,0,0,1}) is basically what avformat based code was doing, i didn't realize it's needed in this case too. Though in a way things were easier, the data was just accumulated and then fed to the avformat, no need to subclass and follow (unknown to me (yet?)) rules of processing, perhaps there exists an example of something similar in the source tree already? Thank you. -- mailto:av1474 at comtv.ru From fantasyvideo at 126.com Thu Sep 13 02:07:40 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Thu, 13 Sep 2012 17:07:40 +0800 Subject: [Live-devel] regardint every rtp packet's timestamp is same Message-ID: <000001cd918f$3bfb53d0$b3f1fb70$@126.com> I used live555 to stream g711, My code is like this: RTPSink* AudioOnDemandMediaSubsession::createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource) { char const* mimeType=?PCMU?; unsigned char payloadFormatCode=0; int sampleFrequency = 8000; unsigned int numChannels = 1; return SimpleRTPSink::Create(envir(),rtpGroupsock,payloadFormatCode,sampleFrequency ,?audio?,mimeType,numChannels); } In another side, I use VLC to access, but I found that every rtp packet?s timestamp is same. And only if I close the audio rtsp server, then the vlc would start play the audio. It?s so strange that I didn?t know where is wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 13 02:33:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Sep 2012 02:33:59 -0700 Subject: [Live-devel] regardint every rtp packet's timestamp is same In-Reply-To: <000001cd918f$3bfb53d0$b3f1fb70$@126.com> References: <000001cd918f$3bfb53d0$b3f1fb70$@126.com> Message-ID: > I used live555 to stream g711, My code is like this: > RTPSink* AudioOnDemandMediaSubsession::createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource) > { > char const* mimeType=?PCMU?; > unsigned char payloadFormatCode=0; > int sampleFrequency = 8000; > unsigned int numChannels = 1; > return SimpleRTPSink::Create(envir(),rtpGroupsock,payloadFormatCode,sampleFrequency,?audio?,mimeType,numChannels); > } This looks OK. But what about your "createNewStreamSource()" implementation?? > In another side, I use VLC to access, but I found that every rtp packet?s timestamp is same. That's probably because you are not setting "fPresentationTime" correctly in your input source class - i.e., the class that encapsulates your G.711 audio source. You haven't said anything about this... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Thu Sep 13 03:34:39 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Thu, 13 Sep 2012 18:34:39 +0800 Subject: [Live-devel] =?gb2312?b?tPC4tDogIHJlZ2FyZGludCBldmVyeSBydHAgcGFj?= =?gb2312?b?a2V0J3MgdGltZXN0YW1wIGlzIHNhbWU=?= In-Reply-To: References: <000001cd918f$3bfb53d0$b3f1fb70$@126.com> Message-ID: <000001cd919b$6267a350$2736e9f0$@126.com> My createNewStreamSource code is like this: { estBitrate = 64; return new AudioFramedSource(envir(),?test?); } And the AudioFrameSource main code is like this: void AudioFrameSource::doGetNextFrame() { CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize,&fFr ameSize,&fNumTruncatedBytes); fPresentationTime.tv_sec=usec/1000; fPresentationTime.tv_usec = usec%1000; usec+=200; nextTask()=envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSo urce::afterGetting,this); } But even if I add the fPresentationTime, vlc still can?t play it. But the mplayer can play. ???: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] ?? Ross Finlayson ????: 2012?9?13? 17:34 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] regardint every rtp packet's timestamp is same I used live555 to stream g711, My code is like this: RTPSink* AudioOnDemandMediaSubsession::createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource) { char const* mimeType=?PCMU?; unsigned char payloadFormatCode=0; int sampleFrequency = 8000; unsigned int numChannels = 1; return SimpleRTPSink::Create(envir(),rtpGroupsock,payloadFormatCode,sampleFrequency ,?audio?,mimeType,numChannels); } This looks OK. But what about your "createNewStreamSource()" implementation?? In another side, I use VLC to access, but I found that every rtp packet?s timestamp is same. That's probably because you are not setting "fPresentationTime" correctly in your input source class - i.e., the class that encapsulates your G.711 audio source. You haven't said anything about this... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 503430770 at qq.com Thu Sep 13 07:40:48 2012 From: 503430770 at qq.com (=?gb18030?B?Li4u?=) Date: Thu, 13 Sep 2012 22:40:48 +0800 Subject: [Live-devel] about rtsp client. Message-ID: Hi,all. I use live555 as server, I want to create a RTSP client on one PC(PC_a),and receive the RTP/RTCP data on another(PC_b).How can I do? I see the RTSP Interaction?I think I should to tell LIVE555 the IP of PC_b in "SETUP" stage to achieve the goal. But I don't know how to do it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 13 08:55:07 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Sep 2012 08:55:07 -0700 Subject: [Live-devel] regardint every rtp packet's timestamp is same In-Reply-To: <000001cd919b$6267a350$2736e9f0$@126.com> References: <000001cd918f$3bfb53d0$b3f1fb70$@126.com> <000001cd919b$6267a350$2736e9f0$@126.com> Message-ID: <16D085F9-4358-45BE-804C-F8243BA2579D@live555.com> > And the AudioFrameSource main code is like this: > void AudioFrameSource::doGetNextFrame() > { > CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize,&fFrameSize,&fNumTruncatedBytes); > fPresentationTime.tv_sec=usec/1000; > fPresentationTime.tv_usec = usec%1000; > usec+=200; Why do you have a variable named "usec", when its value appears to be in milliseconds, not microseconds? But anyway, assuming that "usec" is really intended to be a value in milliseconds: You need to be aware of the following: 1/ The very first value of "usec" - i.e., the value that's used when "doGetNextFrame()" is called for the first time - must be aligned with 'wall clock' time - i.e., the time that you'd get by calling "gettimeofday()". This is important for RTCP-based timing to work properly. 2/ Because you have specified a sampling frequency of 8000 samples per second, the length of time that you increment "usec" by each time that "GetAudioFrame()" is called needs to correspond to the number of samples that "GetAudioFrame()" has returned. The value you are currently incrementing "usec" by - 200 ms - is almost certainly wrong, because 200 ms corresponds to 8000*0.2 == 1600 audio samples, which will be too big for an outgoing RTP packet (assuming default packet size settings). (Note that each 1-channel u-law audio sample will take up 1 byte.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ketangholap1990 at gmail.com Thu Sep 13 08:37:19 2012 From: ketangholap1990 at gmail.com (Ketan Gholap) Date: Thu, 13 Sep 2012 21:07:19 +0530 Subject: [Live-devel] Live stream receiving problem Message-ID: Hello Sir! I have created RTSPServer application. In this application server receives live stream from a Live media Streamer application which in turn get steam from digital camera. my .net web application creates a socket connection and RTSP session with RTSPserver. After that my .net application receives and display live stream successfully. While doing so, if I try to connect to RTSPserver form VLC media player then VLC is unable to receive the stream. And also creates problem for our .net web application to receive stream. On the other hand, If VLC creates RTSPsession before our .net application then it works fine. Even our .net application also work fine after this. In short we have observed that when there is issue in receiving stream from both VLC and our .net application if our application creates RTSPSession first. RTSP Session Requests and Responses from our .net web application is as follows.. * SETUP rtsp://RTSPServerIP:Tunneling port/ StreamName RTSP/1.0\r\nCSeq: 2\r\nTransport: RTP/AVP/TCP;interleaved=0-1\r\n\r\n; RTSP/1.0 200 OK CSeq: 2 Date: Thu, Sep 13 2012 15:00:24 GMT Transport: RTP/AVP/TCP;unicast;destination=destinationIP ;source=source IP;interleaved=0-1 Session: 7F3AB815 PLAY rtsp://RTSPServerIP:Tunneling port/ StreamName RTSP/1.0 CSeq: 3 Session: A1E27785 RTSP/1.0 200 OK CSeq: 3 Date: Thu, Sep 13 2012 15:00:24 GMT Session: 7F3AB815 RTP-Info: url=rtsp:// RTSPServerIP/ StreamName/track1;seq=50968;rtptime=1218052426 * I don't have any idea how exactly VLC does it with RTSP Server..it might happen our request creates some problem to create further session by VLC? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 13 13:16:25 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Sep 2012 13:16:25 -0700 Subject: [Live-devel] about rtsp client. In-Reply-To: References: Message-ID: <52EBEFCA-2FCA-4CDD-8CAE-35CBEEA24728@live555.com> > I use live555 as server, I want to create a RTSP client on one PC(PC_a),and receive the RTP/RTCP data on another(PC_b).How can I do? There is a way in the RTSP protocol to do this: specify the intended receiver (PC_b)'s IP address as a destination=; parameter in a "Transport:" header in the RTSP "SETUP" request. However, our RTSP client implementation *does not* support this (nor are there any plans to do so). Our RTSP server implementation, however, does support this, but not by default. To enable this support in our RTSP server, you'll need to add #define RTSP_ALLOW_CLIENT_DESTINATION_SETTING 1 to the start of "RTSPServer.cpp", and recompile. You should be warned, however, that this is a security risk; it allows your server to be used for 'denial of server' attacks. (This is why this mechanism is not supported by default in our RTSP server implementation, and not supported at all in our RTSP client implementation.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpeng at google.com Thu Sep 13 10:20:54 2012 From: dpeng at google.com (Daniel Peng) Date: Thu, 13 Sep 2012 13:20:54 -0400 Subject: [Live-devel] [patch] make live555 playback h.264 RTSP streams from Foscam IP cameras Message-ID: Hi folks, I have a Foscam h.264 IP camera with a very strange RTSP-over-HTTP server, and I wanted to get VLC to play it back. There are two basic issues: 1. On an OPTIONS request, the server returns HTTP 501 (Unimplemented) but omits the Cseq. Liblivemedia erroneously matched this to the POST request rather than the OPTIONS request. To fix this, don't enqueue POST requests in fRequestsAwaitingResponse. 2. The server returns packets bigger than 10,000 bytes. Bump the constant to 20,000 and also log a diagnostic when it's exceeded. I've attached a patch. I have a separate patch for VLC to handle the failed OPTIONS response. Thanks, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: liblivemedia.patch Type: application/octet-stream Size: 2287 bytes Desc: not available URL: From finlayson at live555.com Thu Sep 13 16:34:25 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Sep 2012 16:34:25 -0700 Subject: [Live-devel] [patch] make live555 playback h.264 RTSP streams from Foscam IP cameras In-Reply-To: References: Message-ID: <20392C3E-E48F-47DC-AA32-22B78EF1F196@live555.com> > 1. On an OPTIONS request, the server returns HTTP 501 (Unimplemented) > but omits the Cseq. Liblivemedia erroneously matched this to the POST > request rather than the OPTIONS request. To fix this, don't enqueue > POST requests in fRequestsAwaitingResponse. Thanks. I've just installed a new version (2012.09.13) of the "LIVE555 Streaming Media" software that includes this fix. > 2. The server returns packets bigger than 10,000 bytes. Bump the > constant to 20,000 and also log a diagnostic when it's exceeded. OK, thanks (though I moved the diagnostic error message to "MultiFramedRTPSource.cpp" and "RTCP.cpp", because those use different 'input buffer size' constants). FYI, you don't need to use VLC to test "RTSP-over-HTTP". Our "openRTSP" demo application can also be used for this. (Note the "-T " option.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpeng at google.com Thu Sep 13 20:21:27 2012 From: dpeng at google.com (Daniel Peng) Date: Thu, 13 Sep 2012 23:21:27 -0400 Subject: [Live-devel] [patch] make live555 playback h.264 RTSP streams from Foscam IP cameras In-Reply-To: <20392C3E-E48F-47DC-AA32-22B78EF1F196@live555.com> References: <20392C3E-E48F-47DC-AA32-22B78EF1F196@live555.com> Message-ID: On Thu, Sep 13, 2012 at 7:34 PM, Ross Finlayson wrote: > FYI, you don't need to use VLC to test "RTSP-over-HTTP". Our "openRTSP" > demo application can also be used for > this. (Note the "-T " option.) Thank you for the quick response! This is a very helpful tip too, thanks. Recompiling VLC for each tweak to Live555 was a bit of a pain. :) Best, Daniel From fantasyvideo at 126.com Thu Sep 13 22:46:11 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Fri, 14 Sep 2012 13:46:11 +0800 Subject: [Live-devel] =?gb2312?b?tPC4tDogIHJlZ2FyZGludCBldmVyeSBydHAgcGFj?= =?gb2312?b?a2V0J3MgdGltZXN0YW1wIGlzIHNhbWU=?= In-Reply-To: <16D085F9-4358-45BE-804C-F8243BA2579D@live555.com> References: <000001cd918f$3bfb53d0$b3f1fb70$@126.com> <000001cd919b$6267a350$2736e9f0$@126.com> <16D085F9-4358-45BE-804C-F8243BA2579D@live555.com> Message-ID: <002e01cd923c$40661f60$c1325e20$@126.com> Thank you for your answer. Now I change the code as below: AudioFramedSource::AudioFrameSource() { gettimeofday(&m_timescale); } void AudioFrameSource::doGetNextFrame() { CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize,&fFr ameSize,&fNumTruncatedBytes); Int64_t usec = m_timescale.tv_usec; usec += 40/8; //since every frame has 40 samples. If(usec>=1000) { m_timescale.tv_sec+= usec/1000; m_timescale.tv_usec += usec%1000; } else { m_timescale.tv_usec = usec; } fPresentationTime = m_timescale; } With the above code, then the timestamp seems created correct. But the vlc still can?t play it correctly, as I know , vlc accesses rtsp by using live555. The mplayer can work. ???: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] ?? Ross Finlayson ????: 2012?9?13? 23:55 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] regardint every rtp packet's timestamp is same And the AudioFrameSource main code is like this: void AudioFrameSource::doGetNextFrame() { CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize,&fFr ameSize,&fNumTruncatedBytes); fPresentationTime.tv_sec=usec/1000; fPresentationTime.tv_usec = usec%1000; usec+=200; Why do you have a variable named "usec", when its value appears to be in milliseconds, not microseconds? But anyway, assuming that "usec" is really intended to be a value in milliseconds: You need to be aware of the following: 1/ The very first value of "usec" - i.e., the value that's used when "doGetNextFrame()" is called for the first time - must be aligned with 'wall clock' time - i.e., the time that you'd get by calling "gettimeofday()". This is important for RTCP-based timing to work properly. 2/ Because you have specified a sampling frequency of 8000 samples per second, the length of time that you increment "usec" by each time that "GetAudioFrame()" is called needs to correspond to the number of samples that "GetAudioFrame()" has returned. The value you are currently incrementing "usec" by - 200 ms - is almost certainly wrong, because 200 ms corresponds to 8000*0.2 == 1600 audio samples, which will be too big for an outgoing RTP packet (assuming default packet size settings). (Note that each 1-channel u-law audio sample will take up 1 byte.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 13 23:21:55 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Sep 2012 23:21:55 -0700 Subject: [Live-devel] =?utf-8?b?562U5aSNOiAgcmVnYXJkaW50IGV2ZXJ5IHJ0cCBw?= =?utf-8?q?acket=27s_timestamp_is_same?= In-Reply-To: <002e01cd923c$40661f60$c1325e20$@126.com> References: <000001cd918f$3bfb53d0$b3f1fb70$@126.com> <000001cd919b$6267a350$2736e9f0$@126.com> <16D085F9-4358-45BE-804C-F8243BA2579D@live555.com> <002e01cd923c$40661f60$c1325e20$@126.com> Message-ID: <39B09E85-4E19-4DE0-936F-0E6119840A8D@live555.com> > Thank you for your answer. > Now I change the code as below: > AudioFramedSource::AudioFrameSource() > { > gettimeofday(&m_timescale); OK, this is good, in principle. It aligns the presentation time with 'wall-clock' time. However, the constructor is not the right time to be calling "gettimeofday()", because you don't know how long you'll be waiting until "doGetNextFrame()" is first called. Instead, declare a member variable Boolean fIsFirstPresentationTime; and, in the constructor, do fIsFirstPresentationTime = True; > void AudioFrameSource::doGetNextFrame() > { > CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize,&fFrameSize,&fNumTruncatedBytes); > Int64_t usec = m_timescale.tv_usec; > usec += 40/8; //since every frame has 40 samples. > If(usec>=1000) > { > m_timescale.tv_sec+= usec/1000; > m_timescale.tv_usec += usec%1000; > } > else > { > m_timescale.tv_usec = usec; > } This is all very wrong, because the "tv_usec" field is in microseconds, but you're treating it as if it were in milliseconds. Also, you're incrementing "fPresentationTime" too soon. The correct code would be something like this: void AudioFrameSource::doGetNextFrame() { CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize,&fFrameSize,&fNumTruncatedBytes); if (fIsFirstPresentationTime) { gettimeofday(&m_timescale); fIsFirstPresentationTime = False; // from now on } fPresentationTime = m_timescale; fDurationInMicroseconds = 5000; // because 40 samples at 8000 samples-per-second have a duration of 5 ms (== 5000 us) // Compute the next presentation time (i.e., to be used on the next call to "doGetNextFrame()"): m_timescale.tv_usec += fDurationInMicroseconds; if (m_timescale.tv_usec > 1000000) { ++m_timescale.tv_sec; m_timescale.tv_usec -= 1000000; } } Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmdaa at iscte.pt Fri Sep 14 01:48:20 2012 From: jmdaa at iscte.pt (jmdaa at iscte.pt) Date: Fri, 14 Sep 2012 09:48:20 +0100 Subject: [Live-devel] SVC multi streaming transmission of separate layers Message-ID: <6dc7362377e3079aae8a3d28ff2fa3b5@iscte.pt> DO YOU KNOW A WAY TO CHANGE THE SETUPRTSP IN YOUR CLIENT CODE (OPENRTSP) TO INDICATE THAT THE TWO TRACK GO TO TWO DIFFERENT IP (INTERFACE) FOR EXAMPLE: 4,0.002474,195.134.1.6,195.134.1.2,RTSP/SDP,Reply:RTSP/1.0200OK,withsessiondescription 5,0.004125,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.3/spatialSoc_basenh3.mp4/trackID=65536RTSP/1.0 6,0.004885,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 7,0.005351,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.6/spatialSoc_basenh3.mp4/trackID=65538RTSP/1.0 >................ >But if your intention is to send the two video tracks to different interfaces within the same client, then the best way to do this is to keep things the way that they work now: >Send both streams to the same (client) IP address, but with different port numbers. >Ross Finlayson Thks for your advices. I thought that the interfaces were defined only on the client side with different ip's. Please could you show me how to represent the different interfaces through the ports. Also in my project we use a MP4 container that contains the two videos track hinted, it allows the server to stream a unknown payload . For example the standard DSS can do streaming of h264/SVC with your openRST and openSVC decoder. But your server does not handle MP4 containers or hinting, does it? best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 14 01:59:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2012 01:59:03 -0700 Subject: [Live-devel] SVC multi streaming transmission of separate layers In-Reply-To: <6dc7362377e3079aae8a3d28ff2fa3b5@iscte.pt> References: <6dc7362377e3079aae8a3d28ff2fa3b5@iscte.pt> Message-ID: <46581D44-75E1-4469-8040-8403BC298DEC@live555.com> > Thks for your advices. I thought that the interfaces were defined only on the client side with different ip's. Please could you show me how to represent the different interfaces through the ports. Sorry, but I don't really understand this question. If you create and run your "RTSPClient" in the normal way - without any changes - then each track within the stream will already be sent to a separate port, on the same (client) host. > Also in my project we use a MP4 container that contains the two videos track hinted, it allows the server to stream a unknown payload . For example the standard DSS can do streaming of h264/SVC with your openRST and openSVC decoder. But your server does not handle MP4 containers or hinting, does it? No. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Fri Sep 14 01:22:33 2012 From: kingaceck at 163.com (kingaceck) Date: Fri, 14 Sep 2012 16:22:33 +0800 Subject: [Live-devel] A problem of video pause when streaming mpg file Message-ID: <201209141622286258386@163.com> Dear Ross Finlayson : (1) I play the file using vlc like this:rtsp://129.1.5.155/test.mpg.After I clicked the PAUSE button and then clicked the PLAY button,the time at the lower left corner of vlc is becoming 00:00.Actually Before I click PAUSE button it is 2:05.what's the reason of this? (2) When replaying after click PLAY button(before to do this I clicked PAUSE button),at the first 5 seconds the video quiver. what can I do to fix this problem? please help me.Thank you very much. 2012-09-14 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Fri Sep 14 02:03:45 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Fri, 14 Sep 2012 17:03:45 +0800 Subject: [Live-devel] =?gb2312?b?tPC4tDogILTwuLQ6ICByZWdhcmRpbnQgZXZlcnkg?= =?gb2312?b?cnRwIHBhY2tldCdzIHRpbWVzdGFtcCBpcyBzYW1l?= In-Reply-To: <39B09E85-4E19-4DE0-936F-0E6119840A8D@live555.com> References: <000001cd918f$3bfb53d0$b3f1fb70$@126.com> <000001cd919b$6267a350$2736e9f0$@126.com> <16D085F9-4358-45BE-804C-F8243BA2579D@live555.com> <002e01cd923c$40661f60$c1325e20$@126.com> <39B09E85-4E19-4DE0-936F-0E6119840A8D@live555.com> Message-ID: <005c01cd9257$d9729e70$8c57db50$@126.com> I did as you said, then use vlc to access. But it would stop automatically after some seconds, and shows that ?Program doesn?t contain anymore ES?. Buf if I comment the fDurationInMicroseconds=5000, it was getting the buffer although it?s 0%. ???: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] ?? Ross Finlayson ????: 2012?9?14? 14:22 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] ??: regardint every rtp packet's timestamp is same Thank you for your answer. Now I change the code as below: AudioFramedSource::AudioFrameSource() { gettimeofday(&m_timescale); OK, this is good, in principle. It aligns the presentation time with 'wall-clock' time. However, the constructor is not the right time to be calling "gettimeofday()", because you don't know how long you'll be waiting until "doGetNextFrame()" is first called. Instead, declare a member variable Boolean fIsFirstPresentationTime; and, in the constructor, do fIsFirstPresentationTime = True; void AudioFrameSource::doGetNextFrame() { CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize,&fFr ameSize,&fNumTruncatedBytes); Int64_t usec = m_timescale.tv_usec; usec += 40/8; //since every frame has 40 samples. If(usec>=1000) { m_timescale.tv_sec+= usec/1000; m_timescale.tv_usec += usec%1000; } else { m_timescale.tv_usec = usec; } This is all very wrong, because the "tv_usec" field is in microseconds, but you're treating it as if it were in milliseconds. Also, you're incrementing "fPresentationTime" too soon. The correct code would be something like this: void AudioFrameSource::doGetNextFrame() { CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize, &fFrameSize,&fNumTruncatedBytes); if (fIsFirstPresentationTime) { gettimeofday(&m_timescale); fIsFirstPresentationTime = False; // from now on } fPresentationTime = m_timescale; fDurationInMicroseconds = 5000; // because 40 samples at 8000 samples-per-second have a duration of 5 ms (== 5000 us) // Compute the next presentation time (i.e., to be used on the next call to "doGetNextFrame()"): m_timescale.tv_usec += fDurationInMicroseconds; if (m_timescale.tv_usec > 1000000) { ++m_timescale.tv_sec; m_timescale.tv_usec -= 1000000; } } Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmdaa at iscte.pt Fri Sep 14 02:29:50 2012 From: jmdaa at iscte.pt (jmdaa at iscte.pt) Date: Fri, 14 Sep 2012 10:29:50 +0100 Subject: [Live-devel] SVC multi streaming transmission of separate layers Message-ID: >>Thks for your advices. I thought that the interfaces were defined only on the client side with different ip's. Please could you show me how to represent the different interfaces through the ports. >Sorry, but I don't really understand this question. >If you create and run your "RTSPClient" in the normal way - without > any changes - then each track within the stream will already be sent to > a separate port, on the same (client) host. >Ross Finlayson Ok i will try to explain better. Here you say "But if your intention is to send the two video tracks to different interfaces within the same client, then the best way to do this is to keep things the way that they work now: Send both streams to the same (client) IP address, but with different port numbers." This mean i need to identify the different port numbers (in my case 64322 and 64324) as the different interfaces, for example 64322 will be wifi and 64324 the ethernet, it this possible and how i will do that? thks From finlayson at live555.com Fri Sep 14 02:31:06 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2012 02:31:06 -0700 Subject: [Live-devel] A problem of video pause when streaming mpg file In-Reply-To: <201209141622286258386@163.com> References: <201209141622286258386@163.com> Message-ID: Please reword your question so that it explains specifically how it concerns our software. (Note that VLC is not our software.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 14 03:04:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2012 03:04:05 -0700 Subject: [Live-devel] SVC multi streaming transmission of separate layers In-Reply-To: References: Message-ID: <8D3E1575-97C6-4F02-8E1A-9DD73494099F@live555.com> > This mean i need to identify the different port numbers (in my case 64322 and 64324) as the different interfaces, for example 64322 will be wifi and 64324 the ethernet, it this possible No - sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashfaque at iwavesystems.com Fri Sep 14 03:12:28 2012 From: ashfaque at iwavesystems.com (Ashfaque) Date: Fri, 14 Sep 2012 15:42:28 +0530 Subject: [Live-devel] Streaming distorted on another client device Message-ID: <1672320D665C45998C8A76F8328FE9D5@iwns10> Hi Ross, We are facing a particular problem, when streaming is happening between a transmitter board and iPad. Here Transmitter board is configured as an Access Point, when another client device is connected to this board(but Rx Streaming application is not started) , Streaming on the already connected device is being effected. Video is been displayed with a large delay. When the Rx application is started on the another receiver device, streaming is proper on both client devices. Tx application is running in multicast streaming mode. Here both Tx and Rx applications are live555 based. Please let us know the cause of this issue. Thanks & Regards, Ahamed -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Fri Sep 14 11:54:47 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Fri, 14 Sep 2012 18:54:47 +0000 Subject: [Live-devel] Re-connection handling In-Reply-To: <4EE959A2-046E-46BD-9951-FB3279CBCA89@live555.com> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <4EE959A2-046E-46BD-9951-FB3279CBCA89@live555.com> Message-ID: There is one case where it doesn't work though, and I'm not sure how to handle it. This is if I do a seek while the stream is disconnected, then it never reconnects. In some cases I play a 10s loop where a timer do a seek every 10s and jumps back (using absolute seeking). Those streams never reconnect after a disconnection. OK, so unless you can tell me a reliable way to reproduce this problem (perhaps using "openRTSP), then you'll need to figure out yourself why the LIVE555 library's connection reestablishment code is not working in this case (and then I'll try to fix it). Remember, You Have Complete Source Code. The place to look in the code is near the start of "RTSPClient::sendRequest()" (line 535 of "liveMedia/RTSPClient.cpp"). When you do your 'seek' (really "PLAY") operation (that's failing), then is "fInputSocketNum" <0? If so, then what value does "openConnection()" return. If, however, "fInputSocketNum" is >= 0 (in practice, it will be >0), then we will (eventually) call "send()" (at line 787) to transmit the command. Is this "send()" call succeeding, or not? I've finally come around to try to dig deeper into this reconnect issue. First, I'd like to point out that I've updated to the latest liveMedia code (2012.09.13) and I've redesigned my program to only access/create liveMedia objects/functions within a function triggered by triggerEvent(). I put some debug messages in RTSPClient::sendRequest(), but it doesn't seem to end up there when I do the seek. I do get an exception at random locations. Sometimes it happens without me doing anything, i.e. directly when the connection has been re-established, other times the exception occurs after I try to do something to the RTSP stream, e.g. stop or seek. Below is an example of the call stack for an exception: ... msvcr90d.dll!_free_base(void * pBlock=0x61d4d496) msvcr90d.dll!_unlock(int locknum=4) msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0) msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0) msvcr90d.dll!_free_base(void * pBlock=0x05051718) msvcr90d.dll!strerror(int errnum=111825400) RtspVideo.dll!BasicUsageEnvironment0::setResultErrMsg() RtspVideo.dll!readsocket() RtspVideo.dll!RTSPClient::incomingDataHandler() RtspVideo.dll!BasicTaskScheduler::SingleStep() RtspVideo.dll!BasicTaskScheduler0::doEventLoop() ... here is another one: ... msvcr90d.dll!malloc(unsigned int size=21) msvcr90d.dll!operator new(unsigned int size=21) RtspVideo.dll!BasicTaskScheduler::SingleStep() RtspVideo.dll!BasicTaskScheduler0::doEventLoop() ... Please let me know what I can do to help. I'll continue to look in to this. Again, what I do is: 1. Play an archive (i.e. non-live) stream. 2. Unplug Ethernet cable. 3. Do a seek while disconnected. 4. Plug in Ethernet cable. I get an exception every time, but as mentioned above, it appears slightly different and the call stack usually looks different each time. /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From chris at gotowti.com Fri Sep 14 12:17:36 2012 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Fri, 14 Sep 2012 12:17:36 -0700 Subject: [Live-devel] Re-connection handling In-Reply-To: References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <4EE959A2-046E-46BD-9951-FB3279CBCA89@live555.com> Message-ID: <04c601cd92ad$99eff5d0$cdcfe170$@com> Hi, The exceptions you are seeing are almost certainly the result of heap corruption in your code, which is going to become quickly off-topic for this list. However to get you started on fixing this problem: The heap is being validated during the CRT heap calls in debug mode, which explains why you see the exception happening with different call stacks. One way to help diagnose heap corruption is to place "assert( _CrtCheckMemory() );" in various places where you think the corruption may be occurring. That will force a heap validation in a known location, rather than just relying on the CRT debug heap functions to perform the validation whenever they happen to be called. Chris Richardson WTI From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Erlandsson, Claes P (CERLANDS) Sent: Friday, September 14, 2012 11:55 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Re-connection handling There is one case where it doesn't work though, and I'm not sure how to handle it. This is if I do a seek while the stream is disconnected, then it never reconnects. In some cases I play a 10s loop where a timer do a seek every 10s and jumps back (using absolute seeking). Those streams never reconnect after a disconnection. OK, so unless you can tell me a reliable way to reproduce this problem (perhaps using "openRTSP), then you'll need to figure out yourself why the LIVE555 library's connection reestablishment code is not working in this case (and then I'll try to fix it). Remember, You Have Complete Source Code. The place to look in the code is near the start of "RTSPClient::sendRequest()" (line 535 of "liveMedia/RTSPClient.cpp"). When you do your 'seek' (really "PLAY") operation (that's failing), then is "fInputSocketNum" <0? If so, then what value does "openConnection()" return. If, however, "fInputSocketNum" is >= 0 (in practice, it will be >0), then we will (eventually) call "send()" (at line 787) to transmit the command. Is this "send()" call succeeding, or not? I've finally come around to try to dig deeper into this reconnect issue. First, I'd like to point out that I've updated to the latest liveMedia code (2012.09.13) and I've redesigned my program to only access/create liveMedia objects/functions within a function triggered by triggerEvent(). I put some debug messages in RTSPClient::sendRequest(), but it doesn't seem to end up there when I do the seek. I do get an exception at random locations. Sometimes it happens without me doing anything, i.e. directly when the connection has been re-established, other times the exception occurs after I try to do something to the RTSP stream, e.g. stop or seek. Below is an example of the call stack for an exception: ... msvcr90d.dll!_free_base(void * pBlock=0x61d4d496) msvcr90d.dll!_unlock(int locknum=4) msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0) msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0) msvcr90d.dll!_free_base(void * pBlock=0x05051718) msvcr90d.dll!strerror(int errnum=111825400) RtspVideo.dll!BasicUsageEnvironment0::setResultErrMsg() RtspVideo.dll!readsocket() RtspVideo.dll!RTSPClient::incomingDataHandler() RtspVideo.dll!BasicTaskScheduler::SingleStep() RtspVideo.dll!BasicTaskScheduler0::doEventLoop() ... here is another one: ... msvcr90d.dll!malloc(unsigned int size=21) msvcr90d.dll!operator new(unsigned int size=21) RtspVideo.dll!BasicTaskScheduler::SingleStep() RtspVideo.dll!BasicTaskScheduler0::doEventLoop() ... Please let me know what I can do to help. I'll continue to look in to this. Again, what I do is: 1. Play an archive (i.e. non-live) stream. 2. Unplug Ethernet cable. 3. Do a seek while disconnected. 4. Plug in Ethernet cable. I get an exception every time, but as mentioned above, it appears slightly different and the call stack usually looks different each time. /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 14 14:47:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2012 14:47:03 -0700 Subject: [Live-devel] Re-connection handling In-Reply-To: References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <4EE959A2-046E-46BD-9951-FB3279CBCA89@live555.com> Message-ID: > Again, what I do is: > 1. Play an archive (i.e. non-live) stream. > 2. Unplug Ethernet cable. > 3. Do a seek while disconnected. > 4. Plug in Ethernet cable. > > I get an exception every time This is the first time you've mentioned an exception. (Previously, you said just that the stream failed to reconnect afterwards.) I've attached a modified version of our "testRTSPClient.cpp" demo application. It starts playing the specified stream - as usual - but then, after 60 seconds, sends another "PLAY" command (to seek by 'absolute time'). Please build and run this version of "testRTSPClient", unplugging your Ethernet cable after the initial "PLAY" command. See if an exception occurs after 60 seconds (when the second "PLAY" command (seeking) is sent). If you get an exception in this (modified) "testRTSPClient" application, then let us know; this indicates a bug in the LIVE555 code. If, however, you don't get an exception in this application, then it suggests that the problem occurs only in *your* application, in which case you're going to have to figure this out for yourself. 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: testRTSPClient.cpp Type: application/octet-stream Size: 21086 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From av1474 at comtv.ru Sat Sep 15 11:14:02 2012 From: av1474 at comtv.ru (malc) Date: Sat, 15 Sep 2012 22:14:02 +0400 (MSK) Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: References: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> Message-ID: On Thu, 13 Sep 2012, malc wrote: > On Wed, 12 Sep 2012, Ross Finlayson wrote: > > > > framer = H264VideoStreamFramer::createNew > > > (*env, subsession->readSource (), True/*includeStartCodeInOutput*/); > > > > > > MPEG2TransportStreamFromESSource* tsFrames = > > > MPEG2TransportStreamFromESSource::createNew (*env); > > > tsFrames->addNewVideoSource(framer, 5/*mpegVersion: H.264*/); > > [..snip..] > > > > Instead, *in principle*, you could just feed > > "subsession->readSource()" directly into your > > "MPEG2TransportStreamFromESSource" (via the "addNewVideoSource()" > > call). Unfortunately, however, there's a problem with this: The > > H.264 NAL units that come from the RTP source (i.e., from > > "subsession->readSource()") do not have a 4-byte 'start code' (i.e., > > 0x00 0x00 0x00 0x01) at the front, but that data that you feed into > > a "MPEG2TransportStreamFromESSource" needs to have these start > > codes. > > > > Therefore, you will need to write your own subclass of > > "FramedFilter" that adds a 4-byte 'start code' to each input frame, > > and use an instance of this class - instead of > > "H264VideoStreamFramer" - in front of "subsession->readSource()". > > "Did" that: struct AddStartCodes : FramedFilter { Boolean fHaveWrittenFirstFrame; const char *fSPropParameterSetsStr; unsigned char *mbuf; unsigned mlen; AddStartCodes (UsageEnvironment *env, FramedSource *source, const char *sPropParameterSetsStr) : FramedFilter (*env, source) , fHaveWrittenFirstFrame (False) , fSPropParameterSetsStr (sPropParameterSetsStr) , mbuf (NULL) , mlen (0) { } void addData (const void *buf, size_t size) { mbuf = (unsigned char *) realloc (mbuf, mlen + size); if (!mbuf) die ("realloc %u", mlen); memcpy (mbuf + mlen, buf, size); mlen += size; } void flush (unsigned frameSize) { memmove (fTo + mlen, fTo, frameSize); memcpy (fTo, mbuf, mlen); fFrameSize = frameSize + mlen; mlen = 0; } void afterGettingFrame1 (unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds) { const unsigned char start_code[4] = {0,0,0,1}; if (!fHaveWrittenFirstFrame) { unsigned numSPropRecords; SPropRecord* sPropRecords = parseSPropParameterSets(fSPropParameterSetsStr, numSPropRecords); for (unsigned i = 0; i < numSPropRecords; ++i) { addData (start_code, 4); addData (sPropRecords[i].sPropBytes, sPropRecords[i].sPropLength); } delete[] sPropRecords; fHaveWrittenFirstFrame = True; // for next time } addData (start_code, 4); flush (frameSize); } static void afterGettingFrame (void* clientData, unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds) { AddStartCodes *asc = (AddStartCodes *) clientData; asc->afterGettingFrame1 (frameSize, numTruncatedBytes, presentationTime, durationInMicroseconds); asc->fNumTruncatedBytes = numTruncatedBytes; asc->fPresentationTime = presentationTime; asc->fDurationInMicroseconds = durationInMicroseconds; FramedSource::afterGetting (asc); } virtual void doGetNextFrame () { fInputSource->getNextFrame (fTo, fMaxSize, afterGettingFrame, this, FramedSource::handleClosure, this); } }; However most players[1] are not able to successfully munch the output, those that can't even barf on the out.ts output of testH264VideoToTransportStream (atleast) when in.264 is just a copy of src13_hrc7_525_420_2.264 url to which was given in the original post) [1] mplayer with "native" demuxer (-demuxer lavf works) PlayStation3 -- mailto:av1474 at comtv.ru From finlayson at live555.com Sat Sep 15 14:05:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 15 Sep 2012 14:05:23 -0700 Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: References: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> Message-ID: > those that can't even barf on the out.ts output of > testH264VideoToTransportStream (atleast) when in.264 is just a copy of > src13_hrc7_525_420_2.264 url to which was given in the original post) This should have been the FIRST thing that you told us. I am FAR more interested in reports of problems with our (unmodified) demo applications, because these are often the only problems that I am able to solve. However, in this case, there doesn't seem to be a problem. When I copied your "src13_hrc7_525_420_2.264" file to "in.264" and then ran "testH264VideoToTransportStreamer", the resulting file "out.ts" was playable just fine by VLC (which is generally a superior media player than 'MPlayer'). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From av1474 at comtv.ru Sat Sep 15 14:28:08 2012 From: av1474 at comtv.ru (malc) Date: Sun, 16 Sep 2012 01:28:08 +0400 (MSK) Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: References: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> Message-ID: On Sat, 15 Sep 2012, Ross Finlayson wrote: > > those that can't even barf on the out.ts output of > > testH264VideoToTransportStream (atleast) when in.264 is just a copy of > > src13_hrc7_525_420_2.264 url to which was given in the original post) > > This should have been the FIRST thing that you told us. I am FAR > more interested in reports of problems with our (unmodified) demo > applications, because these are often the only problems that I am > able to solve. I haven't tried it before. > > However, in this case, there doesn't seem to be a problem. When I > copied your "src13_hrc7_525_420_2.264" file to "in.264" and then ran > "testH264VideoToTransportStreamer", the resulting file "out.ts" was > playable just fine by VLC (which is generally a superior media > player than 'MPlayer'). > > Yes it's playable with vlc (and ffplay as mentioned), doesn't make it any less un-playable with PS3 and mplayer though. If, however, i use my old avformat based code the resulting .ts can be chewed by both. -- mailto:av1474 at comtv.ru From finlayson at live555.com Sat Sep 15 14:39:48 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 15 Sep 2012 14:39:48 -0700 Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: References: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> Message-ID: <1F35EB4A-1032-48F5-950F-223E8466EA77@live555.com> > Yes it's playable with vlc (and ffplay as mentioned), doesn't make it > any less un-playable with PS3 and mplayer though. If you find the reason why the resulting Transport Stream file (from "testH264VideoToTransportStream") is unplayable by these players, then please let us know. (There may be something that we can do to our code to overcome this.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From av1474 at comtv.ru Sat Sep 15 14:54:14 2012 From: av1474 at comtv.ru (malc) Date: Sun, 16 Sep 2012 01:54:14 +0400 (MSK) Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: <1F35EB4A-1032-48F5-950F-223E8466EA77@live555.com> References: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> <1F35EB4A-1032-48F5-950F-223E8466EA77@live555.com> Message-ID: On Sat, 15 Sep 2012, Ross Finlayson wrote: > > Yes it's playable with vlc (and ffplay as mentioned), doesn't make it > > any less un-playable with PS3 and mplayer though. > > If you find the reason why the resulting Transport Stream file (from > "testH264VideoToTransportStream") is unplayable by these players, then > please let us know. (There may be something that we can do to our code > to overcome this.) > mplayer spews out this FPS not specified in the header or invalid, use the -fps option. [h264 @ 0x109230d8]no frame! Error while decoding frame! [h264 @ 0x109230d8]non-existing PPS 0 referenced [h264 @ 0x109230d8]decode_slice_header error [h264 @ 0x109230d8]no frame! Error while decoding frame! .... After adding `-fps 25' file plays fine with mplayer, PS3 is less debuggable in this respect as it just says that data is corrupt (which is it's usual (only?) response to the things it can't handle) -- mailto:av1474 at comtv.ru From jshanab at smartwire.com Sat Sep 15 14:56:16 2012 From: jshanab at smartwire.com (Jeff Shanab) Date: Sat, 15 Sep 2012 21:56:16 +0000 Subject: [Live-devel] H264VideoStreamFramer Message-ID: <615FD77639372542BF647F5EBAA2DBC2252185CB@IL-BOL-EXCH01.smartwire.com> >>Yes it's playable with vlc (and ffplay as mentioned), doesn't make it >>any less un-playable with PS3 and mplayer though. When I first got started with video I use VLC as my gauge that things were working correctly. I learned over time tha VLC does an absolutely remarkable job of playing video even when it is missing or has broken headers, It will play a raw file if it at least has the frame markers. I now use it when I want to know if there is something salvageable and to see video most other players cannot, but I have learned to try many players to help support my assertion that I am streaming something correct. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesz5 at wp.pl Sun Sep 16 03:58:10 2012 From: lesz5 at wp.pl (Leszek) Date: Sun, 16 Sep 2012 12:58:10 +0200 Subject: [Live-devel] live555 proxy multiple client issue In-Reply-To: References: Message-ID: Hello I have issue with multiple connections to RTSP proxy: only one client works fine, if i connect second, the 1st freezes... Compiled from latest sources Same as in this thread: http://www.mail-archive.com/live-devel at lists.live555.com/msg08635.html Tried to debug, check logs - everything looks fine Tried connection from other hosts/ systems Tried compile on other linux distros Any ideas ? Regards From finlayson at live555.com Sun Sep 16 08:23:28 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Sep 2012 08:23:28 -0700 Subject: [Live-devel] live555 proxy multiple client issue In-Reply-To: References: Message-ID: <142A72DB-4B6B-42D4-A5B5-EC3B879817EE@live555.com> > I have issue with multiple connections to RTSP proxy: > only one client works fine, if i connect second, the 1st freezes... > Compiled from latest sources > > Same as in this thread: > http://www.mail-archive.com/live-devel at lists.live555.com/msg08635.html > > Tried to debug, check logs - everything looks fine > Tried connection from other hosts/ systems > Tried compile on other linux distros > > Any ideas ? Unfortunately not. When this problem was first reported (back in July), I wasn't able to explain why it was happening, nor was I able to reproduce the problem myself. As far as I know, you're only the second person to be having this problem. The first person was running the proxy server on Windows, so I thought that it might be a Windows-specific problem, but you're reporting that it's happening to you on Linux. So unfortunately it remains (even more of) a mystery to me. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Mon Sep 17 00:27:46 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Mon, 17 Sep 2012 15:27:46 +0800 Subject: [Live-devel] Regarding the audio and video sync Message-ID: <000901cd94a5$f0d7c680$d2875380$@126.com> My session has one video and audio stream. In the audio stream?s doGetNextFrame(), I set the fPresentationTime like this: void AudioFrameSource::doGetNextFrame() { CamerManager::GetInstance()->GetAudioFrame(?test?,(char*)fTo,fMaxSize, &fFrameSize,&fNumTruncatedBytes); if (fIsFirstPresentationTime) { CameraManager::GetInstance()->GetTimeScale(&m_timescale); fIsFirstPresentationTime = False; // from now on } fPresentationTime = m_timescale; fDurationInMicroseconds = 5000; // because 40 samples at 8000 samples-per-second have a duration of 5 ms (== 5000 us) // Compute the next presentation time (i.e., to be used on the next call to "doGetNextFrame()"): m_timescale.tv_usec += fDurationInMicroseconds; if (m_timescale.tv_usec > 1000000) { ++m_timescale.tv_sec; m_timescale.tv_usec -= 1000000; } } In the videoFramesource I set the same timestamp, void VideoFrameSource::doGetNextFrame() { CamerManager::GetInstance()->GetVideoFrame(?test?,(char*)fTo,fMaxSize, &fFrameSize,&fNumTruncatedBytes); if (fIsFirstPresentationTime) { CameraManager::GetInstance()->GetTimeScale(&m_timescale); fIsFirstPresentationTime = False; // from now on } fPresentationTime = m_timescale; fDurationInMicroseconds = 5000; // because 40 samples at 8000 samples-per-second have a duration of 5 ms (== 5000 us) // Compute the next presentation time (i.e., to be used on the next call to "doGetNextFrame()"): m_timescale.tv_usec += fDurationInMicroseconds; if (m_timescale.tv_usec > 1000000) { ++m_timescale.tv_sec; m_timescale.tv_usec -= 1000000; } } But unfortunately, I use vlc to access it, it can?t work correctly. If video is appear, then audio disappears. Otherwise, audio appears, video disappears. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 17 01:07:30 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Sep 2012 01:07:30 -0700 Subject: [Live-devel] Regarding the audio and video sync In-Reply-To: <000901cd94a5$f0d7c680$d2875380$@126.com> References: <000901cd94a5$f0d7c680$d2875380$@126.com> Message-ID: <54D5A48B-1B45-46B4-9A86-3ABD753BF1F6@live555.com> > But unfortunately, I use vlc to access it, it can?t work correctly. If video is appear, then audio disappears. Otherwise, audio appears, video disappears. This is probably because the presentation time ("fPresentationTime") values for the audio and video streams are not properly synchronized. Remember, the audio and video presentation times need to come from the same time base, which needs to be aligned with 'wall clock' time (the time that you would get by calling "gettimeofday()"). You haven't said what your "GetTimeScale()" function (the function that sets the first presentation time for each substream) does, but it needs to be equivalent to calling "gettimeofday()". In any case, I've spent enough time on this - so this will be my last posting on this topic. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvyagintsev at atlantis.ru Mon Sep 17 01:44:23 2012 From: zvyagintsev at atlantis.ru (=?koi8-r?B?+tfRx8nOw8XXIOHO1M/O?=) Date: Mon, 17 Sep 2012 12:44:23 +0400 Subject: [Live-devel] Check for client is still active Message-ID: <003c01cd94b0$a3645930$ea2d0b90$@ru> Hello. As far as I understand to check the client 'connection' still active I need to use some scheduled function, like checkForPacketArrival() in playCommon.cpp (openRTSP) - check the client still received the packets. If no data is coming I need to add/accumulate delay in every scheduled call and if it reach some timeout threshold trigger cleanup function. Am i right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 17 01:56:36 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Sep 2012 01:56:36 -0700 Subject: [Live-devel] Check for client is still active In-Reply-To: <003c01cd94b0$a3645930$ea2d0b90$@ru> References: <003c01cd94b0$a3645930$ea2d0b90$@ru> Message-ID: <690CA3B4-9B47-45FD-903F-E69C6EAD64B0@live555.com> > As far as I understand to check the client ?connection? still active I need to use some scheduled function, like checkForPacketArrival() in playCommon.cpp (openRTSP) ? check the client still received the packets. If no data is coming I need to add/accumulate delay in every scheduled call and if it reach some timeout threshold trigger cleanup function. Am i right? Basically, yes. However, you don't need to use the (rather complicated) method in the "checkForPacketArrival()" code to detect packet arrival. Instead, if you have your own "MediaSink" subclass that's receiving the incoming data, you can use this to flag the arrival of incoming data. You should also note the "TaskScheduler::rescheduleDelayedTask()" function. You can call this function (e.g., from your "MediaSink" subclass) each time that data arrives. This will ensure that the 'delayed task' gets called only if data does not arrive within the specified time. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Mon Sep 17 01:51:46 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Mon, 17 Sep 2012 16:51:46 +0800 Subject: [Live-devel] =?gb2312?b?tPC4tDogIFJlZ2FyZGluZyB0aGUgYXVkaW8gYW5k?= =?gb2312?b?IHZpZGVvIHN5bmM=?= In-Reply-To: <54D5A48B-1B45-46B4-9A86-3ABD753BF1F6@live555.com> References: <000901cd94a5$f0d7c680$d2875380$@126.com> <54D5A48B-1B45-46B4-9A86-3ABD753BF1F6@live555.com> Message-ID: <002c01cd94b1$ac2ffa00$048fee00$@126.com> I get the time by gettimeofday, and they are equal in the video and audio?s stream. ???: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] ?? Ross Finlayson ????: 2012?9?17? 16:08 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] Regarding the audio and video sync But unfortunately, I use vlc to access it, it can?t work correctly. If video is appear, then audio disappears. Otherwise, audio appears, video disappears. This is probably because the presentation time ("fPresentationTime") values for the audio and video streams are not properly synchronized. Remember, the audio and video presentation times need to come from the same time base, which needs to be aligned with 'wall clock' time (the time that you would get by calling "gettimeofday()"). You haven't said what your "GetTimeScale()" function (the function that sets the first presentation time for each substream) does, but it needs to be equivalent to calling "gettimeofday()". In any case, I've spent enough time on this - so this will be my last posting on this topic. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From av1474 at comtv.ru Mon Sep 17 02:57:30 2012 From: av1474 at comtv.ru (malc) Date: Mon, 17 Sep 2012 13:57:30 +0400 (MSK) Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: References: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> <1F35EB4A-1032-48F5-950F-223E8466EA77@live555.com> Message-ID: On Sun, 16 Sep 2012, malc wrote: > On Sat, 15 Sep 2012, Ross Finlayson wrote: > > > > Yes it's playable with vlc (and ffplay as mentioned), doesn't make it > > > any less un-playable with PS3 and mplayer though. > > > > If you find the reason why the resulting Transport Stream file (from > > "testH264VideoToTransportStream") is unplayable by these players, then > > please let us know. (There may be something that we can do to our code > > to overcome this.) > > > > mplayer spews out this > > FPS not specified in the header or invalid, use the -fps option. > [h264 @ 0x109230d8]no frame! > Error while decoding frame! > [h264 @ 0x109230d8]non-existing PPS 0 referenced > [h264 @ 0x109230d8]decode_slice_header error > [h264 @ 0x109230d8]no frame! > Error while decoding frame! > .... > > After adding `-fps 25' file plays fine with mplayer, PS3 is less > debuggable in this respect as it just says that data is corrupt (which > is it's usual (only?) response to the things it can't handle) > FWIW iPad doesn't like the output of testH264VideoToTransportStream either. -- mailto:av1474 at comtv.ru From finlayson at live555.com Mon Sep 17 05:41:21 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Sep 2012 05:41:21 -0700 Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: References: <9308A316-EF6F-4C4B-AC1B-CEC4718F1179@live555.com> <1F35EB4A-1032-48F5-950F-223E8466EA77@live555.com> Message-ID: <936452D6-3E25-46F2-9AD8-214A900067BD@live555.com> >>> If you find the reason why the resulting Transport Stream file (from >>> "testH264VideoToTransportStream") is unplayable by these players, then >>> please let us know. (There may be something that we can do to our code >>> to overcome this.) >>> >> >> mplayer spews out this >> >> FPS not specified in the header or invalid, use the -fps option. >> [h264 @ 0x109230d8]no frame! >> Error while decoding frame! >> [h264 @ 0x109230d8]non-existing PPS 0 referenced >> [h264 @ 0x109230d8]decode_slice_header error >> [h264 @ 0x109230d8]no frame! >> Error while decoding frame! FYI, these error/warning messages - printed by 'MPlayer' - all seem to be about problems in the H.264 video content; not problems in the way in which this content is packed into a Transport Stream. (You would likely get the same messages if you were to stream the ".264" file directly - i.e., without packing it into a Transport Stream - and then try viewing the stream using "MPlayer".) In any case, these problems seem to be caused by the way in which you are generating your H.264 video content (and thus are not directly related to our software, and thus are off-topic for this mailing list). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Mon Sep 17 08:50:42 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Mon, 17 Sep 2012 15:50:42 +0000 Subject: [Live-devel] Re-connection handling In-Reply-To: References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <4EE959A2-046E-46BD-9951-FB3279CBCA89@live555.com> Message-ID: This is the first time you've mentioned an exception. (Previously, you said just that the stream failed to reconnect afterwards.) I've attached a modified version of our "testRTSPClient.cpp" demo application. It starts playing the specified stream - as usual - but then, after 60 seconds, sends another "PLAY" command (to seek by 'absolute time'). Please build and run this version of "testRTSPClient", unplugging your Ethernet cable after the initial "PLAY" command. See if an exception occurs after 60 seconds (when the second "PLAY" command (seeking) is sent). If you get an exception in this (modified) "testRTSPClient" application, then let us know; this indicates a bug in the LIVE555 code. If, however, you don't get an exception in this application, then it suggests that the problem occurs only in *your* application, in which case you're going to have to figure this out for yourself. There is no problem with the liveMedia code, i.e. the testRTSPClient you provided worked fine when I did my disconnect testing. Thanks to this I found the issue. When doing the seek I had the response handler set to continueAfterPLAY instead of NULL. Since the resultCode after the disconnect was -10057 that triggered a call to shutdownStream(). As I after that used the rtspClient pointer it obviously led to the random exceptions I experienced. Your support is very much appreciated. Sorry for bothering you with this issue. /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From kingaceck at 163.com Tue Sep 18 00:08:57 2012 From: kingaceck at 163.com (kingaceck) Date: Tue, 18 Sep 2012 15:08:57 +0800 Subject: [Live-devel] live555ProxyServer issue Message-ID: <201209181508511871557@163.com> Hello I have issue with proxy server at the ubuntu OS: Multiple clients connected to the proxy server(live555ProxyServer) and playing,but when one of them play over,other clients also stop and the following new client can't receive the rtp packet.What's the problem? Thank you very much. 2012-09-18 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 18 04:47:50 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Sep 2012 04:47:50 -0700 Subject: [Live-devel] live555ProxyServer issue In-Reply-To: <201209181508511871557@163.com> References: <201209181508511871557@163.com> Message-ID: > I have issue with proxy server at the ubuntu OS: > Multiple clients connected to the proxy server(live555ProxyServer) and playing,but when one of them play over,other clients also stop and the following new client can't receive the rtp packet.What's the problem? Unfortunately, I don't know. We occasionally receive reports of problems like this, but so far I have not been able to reproduce the problem, nor have I seen a specific explanation of where there's a bug in the code. Until either of those things happens, this is probably going to remain a mystery, unfortunately. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanewu at hotmail.com Wed Sep 19 01:22:10 2012 From: lanewu at hotmail.com (Lei Wu) Date: Wed, 19 Sep 2012 16:22:10 +0800 Subject: [Live-devel] live555 proxy server should send DESCRIBE on reconnect Message-ID: if the back-end stream has failed, proxy server only send "SETUP" and "PLAY" to it, which usually does NOT work. e.g., if a camera rebooted and proper security is enforced, it will return 403 or 401 on "SETUP" without "DESCRIBE". From finlayson at live555.com Wed Sep 19 02:50:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Sep 2012 02:50:15 -0700 Subject: [Live-devel] live555 proxy server should send DESCRIBE on reconnect In-Reply-To: References: Message-ID: <9C5CE3D0-DE87-4085-8B3E-3E759D941054@live555.com> > if the back-end stream has failed, proxy server only send "SETUP" and "PLAY" to it, which usually does NOT work. e.g., if a camera rebooted and proper security is enforced, it will return 403 or 401 on "SETUP" without "DESCRIBE". Yes, you're correct - restarting the connection by sending another "DESCRIBE" will be more reliable. 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 morgan at hsware.net Wed Sep 19 04:34:23 2012 From: morgan at hsware.net (Morgan Segalis) Date: Wed, 19 Sep 2012 13:34:23 +0200 Subject: [Live-devel] using live555 for a p2p VOIP on mobile phone Message-ID: Hi everyone, I would like to have some advice from live555's expert before starting the project and realize that I'll be blocked for something I haven't though of... Here's the whole dilemna : I have already done the whole p2p (hole-punching) connection between users through UDP based on a in-house (beta - might become opensource) protocol. >From that I would like to use iLBC codec to start a call between users. (iLBC seems to be the most supported format) >From what I see live555 is a great (best) library, and I'll really would like to use it, it would ease so much of my work. So here's my questions that I haven't managed to get an answer on this list : - Can we initiate a rtp/rtcp protocol with an already opened udp socket ? - In order to make a voip app, is it necessary to have a rtp server and rtp client on both devices (client 1 connecting to server 2 / client 2 connecting to server 1)? - Using live555, seems to me like using a bazooka to kill a fly. Live555 is so much complete that it seems huge comparing to what I need to do, isn't it ? - Any advice I might have forgotten to take in account about p2p VOIP feature ? Thank you for your help, Morgan -- morgan at hsware.net From zammargu at marvell.com Wed Sep 19 13:01:34 2012 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Wed, 19 Sep 2012 13:01:34 -0700 Subject: [Live-devel] MPEG1or2DemuxedElementaryStream use Message-ID: Hello, I am a very beginner user of live555 use and would like some clarification. I have a program that is able to take an input media file and create an MPEG2-TS file/stream from this input. That works fine for now although I get a lot of dropped packets. But I will not for now worry about this problem yet. Now what I would like to produce is a de-muxed audio/video streams instead of a single MPEG2-TS stream (this stream has PCR, DTS and PTS included). Can I use the MPEG1or2DemuxedElementaryStream method to do that or MPEG1or2Demux should be used? Do these streams get created with time info? Can they be parsed/decoded and rendered? Thanks, -Z. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 19 17:46:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Sep 2012 17:46:24 -0700 Subject: [Live-devel] using live555 for a p2p VOIP on mobile phone In-Reply-To: References: Message-ID: <16E2A9E8-C1EF-416E-8AA0-A0F08B0C2DFA@live555.com> > From that I would like to use iLBC codec to start a call between users. (iLBC seems to be the most supported format) Note that the "LIVE555 Streaming Media" software does not include any codecs (encoding or decoding software). So you would need to supply your own iLBC codec. We do, however, support the RTP Payload Format for iLBC audio (as defined in RFC 3952), using the "SimpleRTPSink" class (for transmission) and the "SimpleRTPSource" class (for reception). > - Can we initiate a rtp/rtcp protocol with an already opened udp socket ? No. However, if you have a port *number*, you can create a "Groupsock" object to use that port number. Its constructor will create the UDP socket for the given port number. Once you have a "Groupsock" object, you can use this to create a "SimpleRTPSink" object (for RTP transmission), or a "SimpleRTPSource" object (for RTP reception). You can also use a separate "Groupsock" object - at each end - to create a "RTCPInstance" object (to implement the RTCP protocol). Note that by convention, RTP uses an even-numbered socket, and RTCP uses the next socket (i.e., an odd-numbered socket). This is not something that's universally enforced, but it's something that you should keep in mind, and try to follow if you can. > - In order to make a voip app, is it necessary to have a rtp server and rtp client on both devices (client 1 connecting to server 2 / client 2 connecting to server 1)? You would need both a "SimpleRTPSink" object and a "SimpleRTPSource" object on each device. > - Using live555, seems to me like using a bazooka to kill a fly. Live555 is so much complete that it seems huge comparing to what I need to do, isn't it ? Yes. Much of the code deals with the RTSP protocol, which is not relevant for your application. Note also that we do not implement SIP, which is the most commonly used control protocol for VoIP. (We do have a rudimentary SIP client implementation, but it falls far short of what you'd need for VoIP.) So, if you're planning to use SIP, you should definitely look elsewhere. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 19 17:52:57 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Sep 2012 17:52:57 -0700 Subject: [Live-devel] MPEG1or2DemuxedElementaryStream use In-Reply-To: References: Message-ID: > Now what I would like to produce is a de-muxed audio/video streams instead of a single MPEG2-TS stream (this stream has PCR, DTS and PTS included). Can I use the MPEG1or2DemuxedElementaryStream method to do that or MPEG1or2Demux should be used? Neither. Unfortunately our software doesn't include a demultiplexor for MPEG Transport Stream. (The "MPEG1or2Demux" etc. classes are used for demultiplexing MPEG *Program* Streams, which are completely different.) If your goal is to stream audio and/or video across the Internet, then you should not be thinking of doing this by multiplexing the audio/video into a Transport Stream, transmitting the Transport Stream, and then demultiplexing the received Transport Stream at the receiver. A MPEG Transport Stream is a very ill-suited format for datagram streaming. Instead, you should by transmitting audio and/or video as separate RTP streams, without any Transport Stream encapsulation. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Sep 20 04:11:54 2012 From: warren at etr-usa.com (Warren Young) Date: Thu, 20 Sep 2012 05:11:54 -0600 Subject: [Live-devel] H.264 in MPEG-2 TS streams roughly at the start In-Reply-To: References: <5049A5B4.1090300@etr-usa.com> <2FD4949D-3D7F-48E7-AB80-97701C3F42C4@live555.com> <504E7D06.5030804@etr-usa.com> <504F70BC.8020900@etr-usa.com> Message-ID: <505AF9FA.2070201@etr-usa.com> On 9/11/2012 2:54 PM, Mojtaba Nouri wrote: > We had the same problem, and we solved it by creating cbr ts files > stuffed with NULL packets. > The following thread shows the ffmpeg command parameters to create h.264 > cbr files: > http://stackoverflow.com/questions/7125446/encoding-h-264-cbr-videos-with-ffmpeg Thanks for the pointer. The magic parameter is -muxrate. The magic involving -x264opts is completely unnecessary. You can use ffmpeg's native bit rate parameters, as I had in my original post. The mux rate needs to be equal to the video bandwidth plus the audio bandwidth, plus 5-10% to cover TS overhead and video encoder peaking. So for 10 Mbit/s video + 128 kbit/s audio, we found it necessary to go with a 12 Mbit/s mux rate to avoid muxing errors. (We didn't tune that very carefully, but we increased from 10128 kbit/s up to about 11.3 Mbit/s before giving up and jumping to 12 Mbit/s.) The other posts claiming that setting min=avg=max == CBR are bogus. libx264 is pretty much incapable of true CBR. You have to do null-stuffing to get a CBR-like result, and even then, you end up with a fair bit of variability. I have bitrate graphs to prove it. :) From zvyagintsev at atlantis.ru Thu Sep 20 04:41:19 2012 From: zvyagintsev at atlantis.ru (=?koi8-r?B?+tfRx8nOw8XXIOHO1M/O?=) Date: Thu, 20 Sep 2012 15:41:19 +0400 Subject: [Live-devel] Enumerate all 'clients' and memory leak Message-ID: <002401cd9724$d9fce9a0$8df6bce0$@ru> Hello. As far as I understand live555 keep track the created 'objects' in internal containers so my guess was it is possible to iterate over that containers. What I need is to enumerate all rtspclients. According to this comment // A data structure for looking up a Medium by its string name. // (It is used only to implement "Medium", but we make it visible here, in case developers want to use it to iterate over // the whole set of "Medium" objects that we've created.) I used MediaLookupTable and my 'environment' pointer: MediaLookupTable* ptable = MediaLookupTable::ourMedia(*pliveenvironment); HashTable const& objects = ptable->getTable(); HashTable::Iterator* piterator = HashTable::Iterator::create(objects); MediaSession* pmediasession; vector clients; // put here all found clients char const* key; while ( (pmediasession = (MediaSession*)piterator->next(key)) != NULL ) if (pmediasession->isRTSPClient()) clients.push_back(pmediasession); // if it is RTSPClient put it to vector delete piterator; This works, but later I noticed a memory leak in MediaLookupTable::ourMedia: MediaLookupTable* MediaLookupTable::ourMedia(UsageEnvironment& env) { _Tables* ourTables = _Tables::getOurTables(env); if (ourTables->mediaTable == NULL) { // Create a new table to record the media that are to be created in // this environment: ourTables->mediaTable = new MediaLookupTable(env); } return ourTables->mediaTable; } My ptable pointer allocated in MediaLookupTable::ourMedia but never deleted, and I can't delete it myself - the destructor is protected. So, I think I am doing something wrong. Maybe another way exists to enumerate all specific objects? WBR -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 20 05:20:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Sep 2012 05:20:20 -0700 Subject: [Live-devel] Enumerate all 'clients' and memory leak In-Reply-To: <002401cd9724$d9fce9a0$8df6bce0$@ru> References: <002401cd9724$d9fce9a0$8df6bce0$@ru> Message-ID: > My ptable pointer allocated in MediaLookupTable::ourMedia but never deleted No, that's incorrect - it *will* get deleted, if/when all "Medium" objects end up getting deleted (so there's no memory leak here). Out of curiosity, though: Why do you want to "enumerate all RTSPClients"? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvyagintsev at atlantis.ru Thu Sep 20 06:08:35 2012 From: zvyagintsev at atlantis.ru (=?utf-8?b?0JfQstGP0LPQuNC90YbQtdCy?= =?utf-8?b?0JDQvdGC0L7QvQ==?=) Date: Thu, 20 Sep 2012 13:08:35 +0000 (UTC) Subject: [Live-devel] Enumerate all 'clients' and memory leak References: <002401cd9724$d9fce9a0$8df6bce0$@ru> Message-ID: Ross Finlayson writes: > My ptable pointer allocated in MediaLookupTable::ourMedia but never deleted > No, that's incorrect - it *will* get deleted, if/when all "Medium" objects end up getting deleted (so there's no memory leak here). Both VLD (visual leak detector) and ms crt debug runtime reports leaks in that code. (Yep, i am still with windows - just doing my job, even after that rtp-over-tcp bug and two days of debugging live555 code :)) If i understand you correctly the only way this leaks possible if the internal container not empty when my program is terminated. BTW, i also interested in removing UsageEnvironment object too. In the sample code you are advised termination code looks like this: pliveenvironment->reclaim(); delete m_plivetaskscheduller; But nobody take care about pliveenvironment itself. So this dynamically allocated memory also reported as a memory leak at the program termination. And again, i can't delete UsageEnvironment myself - destructor is not accessible. > > Out of curiosity, though: Why do you want to "enumerate all RTSPClients"? > To properly shutdown all my RTSPClients. Honestly speaking i have only one RTSPClient running at once :) Anyway i dont want to store my clients in global pointers/another containers/etc because AFAIK live555 already do this. It is enough to work just with callback functions. The only problem is forcible termination from my ('client') side. And one more question, in the samples and the library itself many places in the code looks like this: RTSPClient* rtspClient = ourRTSPClient::createNew(env, rtspURL, RTSP_CLIENT_VERBOSITY_LEVEL, progName); if (rtspClient == NULL) { createNew() just a wrapper over the standard operator new (not overloaded, not a `nothrow` version). But according the c++ standard operator new is never return NULL, but throws bad_alloc on error. Why we need to check the return value? WBR, Anton From zammargu at marvell.com Thu Sep 20 06:12:32 2012 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Thu, 20 Sep 2012 06:12:32 -0700 Subject: [Live-devel] MPEG1or2DemuxedElementaryStream use In-Reply-To: References: Message-ID: Ross, Thanks for your answer. You say: Instead, you should by transmitting audio and/or video as separate RTP streams, without any Transport Stream encapsulation. How do I do that please? Thanks, -Zahira From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, September 19, 2012 8:53 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] MPEG1or2DemuxedElementaryStream use Now what I would like to produce is a de-muxed audio/video streams instead of a single MPEG2-TS stream (this stream has PCR, DTS and PTS included). Can I use the MPEG1or2DemuxedElementaryStream method to do that or MPEG1or2Demux should be used? Neither. Unfortunately our software doesn't include a demultiplexor for MPEG Transport Stream. (The "MPEG1or2Demux" etc. classes are used for demultiplexing MPEG *Program* Streams, which are completely different.) If your goal is to stream audio and/or video across the Internet, then you should not be thinking of doing this by multiplexing the audio/video into a Transport Stream, transmitting the Transport Stream, and then demultiplexing the received Transport Stream at the receiver. A MPEG Transport Stream is a very ill-suited format for datagram streaming. Instead, you should by transmitting audio and/or video as separate RTP streams, without any Transport Stream encapsulation. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 20 06:28:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Sep 2012 06:28:56 -0700 Subject: [Live-devel] MPEG1or2DemuxedElementaryStream use In-Reply-To: References: Message-ID: <4FE7CB02-4CF0-487E-AAAD-4FDBEB013121@live555.com> > You say: > Instead, you should by transmitting audio and/or video as separate RTP streams, without any Transport Stream encapsulation. > > > How do I do that please? It's hard to answer this, because you haven't said anything about your system/environment. Are you using (or planning to use) a RTSP server? If so, then I suggest starting by reviewing the "testOnDemandRTSPServer", and reading the FAQ. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 20 06:37:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Sep 2012 06:37:23 -0700 Subject: [Live-devel] Enumerate all 'clients' and memory leak In-Reply-To: References: <002401cd9724$d9fce9a0$8df6bce0$@ru> Message-ID: <3ECEC68E-8A0A-44D4-B73C-CECA1C8D0FB6@live555.com> >> My ptable pointer allocated in MediaLookupTable::ourMedia but never deleted >> No, that's incorrect - it *will* get deleted, if/when all "Medium" objects end > up getting deleted (so there's no memory leak here). > > Both VLD (visual leak detector) and ms crt debug runtime reports leaks in that > code. Once again, this table will get deleted if (and only if) all "Medium" objects get deleted. (Recall that "Medium" objects are deleted by calling "Medium::close()".) > BTW, i also interested in removing UsageEnvironment object too. In the sample > code you are advised termination code looks like this: > > pliveenvironment->reclaim(); > delete m_plivetaskscheduller; That's correct. Note that the call to "UsageEnvironment::reclaim()" will reclaim all allocated memory, but *only if* all "Medium" objects have already been deleted. But the best/easiest way to reclaim all of the memory for all of the LIVE555-allocated objects is simply to call "exit(0)" - i.e., by exiting the entire process. (But I forget - this is the 21st century. For some odd reason, software developers now have forgotten how to structure their applications using multiple processes :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 20 06:44:46 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Sep 2012 06:44:46 -0700 Subject: [Live-devel] Enumerate all 'clients' and memory leak In-Reply-To: References: <002401cd9724$d9fce9a0$8df6bce0$@ru> Message-ID: <87900AA7-0EA5-4FA8-985D-B7259E24DE3F@live555.com> > And one more question, in the samples and the library itself many places in the > code looks like this: > > RTSPClient* rtspClient = ourRTSPClient::createNew(env, rtspURL, > RTSP_CLIENT_VERBOSITY_LEVEL, progName); > > if (rtspClient == NULL) { > > createNew() just a wrapper over the standard operator new (not overloaded, not a > `nothrow` version). But according the c++ standard operator new is never return > NULL, but throws bad_alloc on error. Why we need to check the return value? Yes, you're correct - in this case, the test for "rtspClient == NULL" is not needed, and could be removed. Note, however, that not all "createNew()" functions are simply wrappers around operator new. "RTSPServer::createNew()", for example, is not. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvyagintsev at atlantis.ru Thu Sep 20 06:55:36 2012 From: zvyagintsev at atlantis.ru (=?utf-8?b?0JfQstGP0LPQuNC90YbQtdCy?= =?utf-8?b?0JDQvdGC0L7QvQ==?=) Date: Thu, 20 Sep 2012 13:55:36 +0000 (UTC) Subject: [Live-devel] Enumerate all 'clients' and memory leak References: <002401cd9724$d9fce9a0$8df6bce0$@ru> <3ECEC68E-8A0A-44D4-B73C-CECA1C8D0FB6@live555.com> Message-ID: Ross Finlayson writes: > > But the best/easiest way to reclaim all of the memory for all of the LIVE555-allocated objects is simply to call "exit(0)" - i.e., by exiting the entire process. ?(But I forget - this is the 21st century. ?For some odd reason, software developers now have forgotten how to structure their applications using multiple processes > Nice irony, but my code (and live555 code also) live in a dynamic link library which is directshow filter (COM object). I cant just 'exit(0)-and-have-fun' :) From zammargu at marvell.com Thu Sep 20 06:49:51 2012 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Thu, 20 Sep 2012 06:49:51 -0700 Subject: [Live-devel] MPEG1or2DemuxedElementaryStream use In-Reply-To: <4FE7CB02-4CF0-487E-AAAD-4FDBEB013121@live555.com> References: <4FE7CB02-4CF0-487E-AAAD-4FDBEB013121@live555.com> Message-ID: Ross, Ok here is more info that might help you help me :) My server is a Linux system. My client is a QNX device. The idea is to use WIFI display (using LIVE555 to build an MPEG2-TS stream) to stream an input multi-media file to the QNX target. It looks likes from your previous email that creating an MPEG2-TS stream is not an ideal thing. Creating an RTP audio stream and a video stream are better suited for this work? With this (small amount) information looking at testOnDemandRTSPServer still holds? Thanks, -Zahira From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, September 20, 2012 9:29 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] MPEG1or2DemuxedElementaryStream use You say: Instead, you should by transmitting audio and/or video as separate RTP streams, without any Transport Stream encapsulation. How do I do that please? It's hard to answer this, because you haven't said anything about your system/environment. Are you using (or planning to use) a RTSP server? If so, then I suggest starting by reviewing the "testOnDemandRTSPServer", and reading the FAQ. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zammargu at marvell.com Thu Sep 20 07:12:29 2012 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Thu, 20 Sep 2012 07:12:29 -0700 Subject: [Live-devel] MPEG1or2DemuxedElementaryStream use In-Reply-To: <4FE7CB02-4CF0-487E-AAAD-4FDBEB013121@live555.com> References: <4FE7CB02-4CF0-487E-AAAD-4FDBEB013121@live555.com> Message-ID: One more thing Ross. The Wifi display standard requires the use of MPEG2-TS. So we don't have much choice about the way the multimedia input is transferred. Thanks. -zahira From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, September 20, 2012 9:29 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] MPEG1or2DemuxedElementaryStream use You say: Instead, you should by transmitting audio and/or video as separate RTP streams, without any Transport Stream encapsulation. How do I do that please? It's hard to answer this, because you haven't said anything about your system/environment. Are you using (or planning to use) a RTSP server? If so, then I suggest starting by reviewing the "testOnDemandRTSPServer", and reading the FAQ. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksandar.milenkovic at rt-rk.com Thu Sep 20 07:48:46 2012 From: aleksandar.milenkovic at rt-rk.com (Aleksandar Milenkovic) Date: Thu, 20 Sep 2012 16:48:46 +0200 Subject: [Live-devel] MPEG demuxing In-Reply-To: References: Message-ID: <505B2CCE.9040007@rt-rk.com> @Zahira you can try demuxing your TS with ffmpeg and then delivering two separate streams for audio and video via RTP-over-RTSP. You will need to reassemble them correctly on the receiving side however, or face terrible lipsync issues. You can wrap both of these as a Transport Stream at the receiving side; however asking further questions about it should better be directed at the ffmpeg crew. Hope that helps. *Aleksandar Milenkovic* Software Engineer Phone: +381-(0)11-2695-244 Fax: +381-(0)21-450-721 Mobile: +381-(0)64-31-666-82 E-mail: Aleksandar.Milenkovic at rt-rk.com RT-RK Computer Based Systems LLC Bulevar Milutina Milankovica 19a 11000 Beograd, Serbia www.rt-rk.com On 9/20/2012 4:09 PM, live-devel-request at ns.live555.com wrote: > 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: MPEG1or2DemuxedElementaryStream use (Ross Finlayson) > 2. Re: Enumerate all 'clients' and memory leak (Ross Finlayson) > 3. Re: Enumerate all 'clients' and memory leak (Ross Finlayson) > 4. Re: Enumerate all 'clients' and memory leak (??????????????) > 5. Re: MPEG1or2DemuxedElementaryStream use (Zahira Ammarguellat) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 20 Sep 2012 06:28:56 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development& use > > Subject: Re: [Live-devel] MPEG1or2DemuxedElementaryStream use > Message-ID:<4FE7CB02-4CF0-487E-AAAD-4FDBEB013121 at live555.com> > Content-Type: text/plain; charset="us-ascii" > >> You say: >> Instead, you should by transmitting audio and/or video as separate RTP streams, without any Transport Stream encapsulation. >> >> >> How do I do that please? > It's hard to answer this, because you haven't said anything about your system/environment. > > Are you using (or planning to use) a RTSP server? If so, then I suggest starting by reviewing the "testOnDemandRTSPServer", and reading the FAQ. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Thu, 20 Sep 2012 06:37:23 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development& use > > Subject: Re: [Live-devel] Enumerate all 'clients' and memory leak > Message-ID:<3ECEC68E-8A0A-44D4-B73C-CECA1C8D0FB6 at live555.com> > Content-Type: text/plain; charset="us-ascii" > >>> My ptable pointer allocated in MediaLookupTable::ourMedia but never deleted >>> No, that's incorrect - it *will* get deleted, if/when all "Medium" objects end >> up getting deleted (so there's no memory leak here). >> >> Both VLD (visual leak detector) and ms crt debug runtime reports leaks in that >> code. > Once again, this table will get deleted if (and only if) all "Medium" objects get deleted. (Recall that "Medium" objects are deleted by calling "Medium::close()".) > > >> BTW, i also interested in removing UsageEnvironment object too. In the sample >> code you are advised termination code looks like this: >> >> pliveenvironment->reclaim(); >> delete m_plivetaskscheduller; > That's correct. Note that the call to "UsageEnvironment::reclaim()" will reclaim all allocated memory, but *only if* all "Medium" objects have already been deleted. > > But the best/easiest way to reclaim all of the memory for all of the LIVE555-allocated objects is simply to call "exit(0)" - i.e., by exiting the entire process. (But I forget - this is the 21st century. For some odd reason, software developers now have forgotten how to structure their applications using multiple processes :-) > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Thu, 20 Sep 2012 06:44:46 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development& use > > Subject: Re: [Live-devel] Enumerate all 'clients' and memory leak > Message-ID:<87900AA7-0EA5-4FA8-985D-B7259E24DE3F at live555.com> > Content-Type: text/plain; charset="us-ascii" > >> And one more question, in the samples and the library itself many places in the >> code looks like this: >> >> RTSPClient* rtspClient = ourRTSPClient::createNew(env, rtspURL, >> RTSP_CLIENT_VERBOSITY_LEVEL, progName); >> >> if (rtspClient == NULL) { >> >> createNew() just a wrapper over the standard operator new (not overloaded, not a >> `nothrow` version). But according the c++ standard operator new is never return >> NULL, but throws bad_alloc on error. Why we need to check the return value? > Yes, you're correct - in this case, the test for "rtspClient == NULL" is not needed, and could be removed. > > Note, however, that not all "createNew()" functions are simply wrappers around operator new. "RTSPServer::createNew()", for example, is not. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 4 > Date: Thu, 20 Sep 2012 13:55:36 +0000 (UTC) > From: ?????????????? > To: live-devel at ns.live555.com > Subject: Re: [Live-devel] Enumerate all 'clients' and memory leak > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Ross Finlayson writes: > >> But the best/easiest way to reclaim all of the memory for all of the > LIVE555-allocated objects is simply to call "exit(0)" - i.e., by exiting the > entire process. ?(But I forget - this is the 21st century. ?For some odd reason, > software developers now have forgotten how to structure their applications using > multiple processes > Nice irony, but my code (and live555 code also) live in a dynamic link library > which is directshow filter (COM object). I cant just 'exit(0)-and-have-fun' :) > > > > ------------------------------ > > Message: 5 > Date: Thu, 20 Sep 2012 06:49:51 -0700 > From: Zahira Ammarguellat > To: LIVE555 Streaming Media - development& use > > Subject: Re: [Live-devel] MPEG1or2DemuxedElementaryStream use > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Ross, > > Ok here is more info that might help you help me :) > My server is a Linux system. My client is a QNX device. The idea is to use WIFI display (using LIVE555 to build an MPEG2-TS stream) to stream an input multi-media file to the QNX target. > It looks likes from your previous email that creating an MPEG2-TS stream is not an ideal thing. Creating an RTP audio stream and a video stream are better suited for this work? > With this (small amount) information looking at testOnDemandRTSPServer still holds? > Thanks, > -Zahira > > > > From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson > Sent: Thursday, September 20, 2012 9:29 AM > To: LIVE555 Streaming Media - development& use > Subject: Re: [Live-devel] MPEG1or2DemuxedElementaryStream use > > You say: > Instead, you should by transmitting audio and/or video as separate RTP streams, without any Transport Stream encapsulation. > > How do I do that please? > > It's hard to answer this, because you haven't said anything about your system/environment. > > Are you using (or planning to use) a RTSP server? If so, then I suggest starting by reviewing the "testOnDemandRTSPServer", and reading the FAQ. > > 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 107, Issue 37 > ******************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Thu Sep 20 10:37:27 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Thu, 20 Sep 2012 10:37:27 -0700 Subject: [Live-devel] Enumerate all 'clients' and memory leak In-Reply-To: References: <002401cd9724$d9fce9a0$8df6bce0$@ru> <3ECEC68E-8A0A-44D4-B73C-CECA1C8D0FB6@live555.com> Message-ID: <505B5457.40208@schuckmannacres.com> In the 21s century people use things like smart pointers and the STL and memory leaks rarely occur. Matt S. On Thursday, September 20, 2012 6:55:36 AM, ?????????????? wrote: > Ross Finlayson writes: > >> >> But the best/easiest way to reclaim all of the memory for all of the > LIVE555-allocated objects is simply to call "exit(0)" - i.e., by exiting the > entire process. (But I forget - this is the 21st century. For some odd reason, > software developers now have forgotten how to structure their applications using > multiple processes >> > > Nice irony, but my code (and live555 code also) live in a dynamic link library > which is directshow filter (COM object). I cant just 'exit(0)-and-have-fun' :) > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Sep 20 15:27:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Sep 2012 15:27:47 -0700 Subject: [Live-devel] Enumerate all 'clients' and memory leak In-Reply-To: References: <002401cd9724$d9fce9a0$8df6bce0$@ru> <3ECEC68E-8A0A-44D4-B73C-CECA1C8D0FB6@live555.com> Message-ID: <8A6918FD-EF42-43F3-843D-7B8AEF9E6ADB@live555.com> >> But the best/easiest way to reclaim all of the memory for all of the > LIVE555-allocated objects is simply to call "exit(0)" - i.e., by exiting the > entire process. (But I forget - this is the 21st century. For some odd reason, > software developers now have forgotten how to structure their applications using > multiple processes >> > > Nice irony, but my code (and live555 code also) live in a dynamic link library > which is directshow filter (COM object). I cant just 'exit(0)-and-have-fun' :) OK, so - in this case - the "software developer who's forgotten how to structure systems using multiple processes" is Microsoft (by not allowing Windows 'Directshow' filters to be processes). Anton is excused :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.shadrin at sprecord.ru Thu Sep 20 23:54:24 2012 From: andrey.shadrin at sprecord.ru (=?UTF-8?B?0JDQvdC00YDQtdC5INCo0LDQtNGA0LjQvQ==?=) Date: Fri, 21 Sep 2012 10:54:24 +0400 Subject: [Live-devel] Cliprect implementation In-Reply-To: <505C0DF7.2090702@sprecord.ru> References: <505C0DF7.2090702@sprecord.ru> Message-ID: <505C0F20.90908@sprecord.ru> Hi Ross Many of the IP camera to transfer the resolution of the frame use the attributes of the "x-dimension" or "cliprect". As the implementation of a "x-dimension" is already present in Live555. Can I suggest implementing a parser for the "cliprect" attribute? Best Regards, Andrey Shadrin, Sarapul Systems, Ltd.. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 1957 bytes Desc: not available URL: From warren at etr-usa.com Fri Sep 21 11:15:30 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 21 Sep 2012 12:15:30 -0600 Subject: [Live-devel] H.264 in MPEG-2 TS streams roughly at the start In-Reply-To: <505AF9FA.2070201@etr-usa.com> References: <5049A5B4.1090300@etr-usa.com> <2FD4949D-3D7F-48E7-AB80-97701C3F42C4@live555.com> <504E7D06.5030804@etr-usa.com> <504F70BC.8020900@etr-usa.com> <505AF9FA.2070201@etr-usa.com> Message-ID: <505CAEC2.1030509@etr-usa.com> On 9/20/2012 5:11 AM, Warren Young wrote: > libx264 is pretty much incapable of true CBR. You have to do > null-stuffing to get a CBR-like result, and even then, you end up with a > fair bit of variability. I have bitrate graphs to prove it. :) Someone emailed me privately asking about those graphs. They were created with an R script I wrote, since I wanted deep visibility into the graph creation process. (I also wanted a second opinion on what I was getting from other bitrate viewer tools.) I asked for and received permission to release that script publicly as free software. It lives here now: https://code.google.com/p/etr-bv/ It's not as fast or as slick or as easy to use as some tools I've used, but when you run the script inside RStudio, you have an amazing amount of power to manipulate the raw statistics, customize the pretty graphics, or answer questions nongraphically. etr-bv even has at least one feature I haven't seen in other tools: it gives min, max, mean *and* standard deviation for the overall data rate. SD is useful in this CBR investigation because it helps you compare two encodes, to see which is "more constant." From finlayson at live555.com Fri Sep 21 17:47:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 Sep 2012 17:47:03 -0700 Subject: [Live-devel] Cliprect implementation In-Reply-To: <505C0F20.90908@sprecord.ru> References: <505C0DF7.2090702@sprecord.ru> <505C0F20.90908@sprecord.ru> Message-ID: Yes, perhaps (though I'm a bit reluctant to support SDP attributes like this that have never been standardized in a RFC). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Fri Sep 21 20:54:51 2012 From: kingaceck at 163.com (kingaceck) Date: Sat, 22 Sep 2012 11:54:51 +0800 Subject: [Live-devel] live555ProxyServer issue Message-ID: <201209221154499376558@163.com> Hi,all. I use live555ProxyServer at the LAN,when more then two client connect to the server playing mp4 file(1080p h264 aac),there are many mosaic and the sound is off and on .If one client connect to the server it is ok.why? After played the new client can't connect to the server.why? Can you help me,thank you. 2012-09-22 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Sep 22 00:26:14 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 Sep 2012 00:26:14 -0700 Subject: [Live-devel] live555ProxyServer issue In-Reply-To: <201209221154499376558@163.com> References: <201209221154499376558@163.com> Message-ID: <7029F8A8-405E-491F-92F1-60EA589E0334@live555.com> > I use live555ProxyServer at the LAN,when more then two client connect to the server playing mp4 file(1080p h264 aac),there are many mosaic and the sound is off and on .If one client connect to the server it is ok.why? Most likely, packet loss. You probably don't have sufficient network capacity to support this number of separate clients. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zammargu at marvell.com Mon Sep 24 12:28:07 2012 From: zammargu at marvell.com (Zahira Ammarguellat) Date: Mon, 24 Sep 2012 12:28:07 -0700 Subject: [Live-devel] MPEG-TS demuxer Message-ID: Hello Thomas, I would be interested in your TS demuxer. Did you write one? Did you follow the algorithm that you have in your message? I would be interested in any information as I am thinking of writing one for our project. Thanks, -Zahira -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanewu at hotmail.com Mon Sep 24 07:14:22 2012 From: lanewu at hotmail.com (Lei Wu) Date: Mon, 24 Sep 2012 14:14:22 +0000 Subject: [Live-devel] can proxy server restore connection faster? Message-ID: Hi, Ross, in the mailing list archive, you mentioned that if the back-end stream server restarted, live555 proxy server can take up to 1 minute to restore the connection. is there a way to restore it ASAP? the waiting period made users think the server is defunct. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Mon Sep 24 14:58:48 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Mon, 24 Sep 2012 14:58:48 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command Message-ID: <5060D798.8080903@schuckmannacres.com> I'm working on upgrading our code to the latest version of LiveMedia (our existing version is quite old) and we had sub classed RTSPClient and implemented a sendSetParametersCommand that sent a SET_PARAMETER command with multiple parameters set in the body to avoid multiple TCP round trips. In looking at the new interface for RTSPClient I can't see how to accomplish the same thing. I think my method should look like this http://pastebin.com/TH3bBcgy However, both fCSeq and fCurrentAuthenticator are both declared private so my sub class can't access them. This would also prevent anyone from implementing their own custom RTSP commands (which is allowed by the standard as long as they don't conflict with the standard ones.) Could you make these variables protected or perhaps add some protected accessors? Thanks, Matt S. From finlayson at live555.com Mon Sep 24 18:33:57 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Sep 2012 18:33:57 -0700 Subject: [Live-devel] can proxy server restore connection faster? In-Reply-To: References: Message-ID: <2C8B2CF9-ACF5-4957-B652-B8A78D9F7CF5@live555.com> > in the mailing list archive, you mentioned that if the back-end stream server restarted, live555 proxy server can take up to 1 minute to restore the connection. is there a way to restore it ASAP? No, because the only way you can find out when the server has restarted is by sending it a command, and checking the response (if any). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 24 18:49:39 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Sep 2012 18:49:39 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: <5060D798.8080903@schuckmannacres.com> References: <5060D798.8080903@schuckmannacres.com> Message-ID: <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> > However, both fCSeq and fCurrentAuthenticator are both declared private so my sub class can't access them. [...] > Could you make these variables protected or perhaps add some protected accessors? I'll make them "protected:", starting with the next release of the software. > This would also prevent anyone from implementing their own custom RTSP commands (which is allowed by the standard as long as they don't conflict with the standard ones.) Yes, although I have no interest in making it easy for people to add their own custom, non-standard extensions to RTSP. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Tue Sep 25 15:39:12 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Tue, 25 Sep 2012 15:39:12 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> References: <5060D798.8080903@schuckmannacres.com> <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> Message-ID: <50623290.9000703@schuckmannacres.com> Thank you. While your at it I noticed that the member fDestinationsHashTable of OnDemandServerMediaSubsession is private while the class Destinations is declared in the header with a comment about it being accessible by subclasses. In addition many of the methods that interact with fDestinationsHashTable like getStreamParameters(), startStream(), endStream(), etc are all declared virtual implying that sub classes should have access to fDestinationsHashTable and it should be declared protected. Matt S. On Monday, September 24, 2012 6:49:39 PM, Ross Finlayson wrote: >> However, both fCSeq and fCurrentAuthenticator are both declared >> private so my sub class can't access them. > [...] >> Could you make these variables protected or perhaps add some >> protected accessors? > > I'll make them "protected:", starting with the next release of the > software. > > >> This would also prevent anyone from implementing their own custom >> RTSP commands (which is allowed by the standard as long as they don't >> conflict with the standard ones.) > > Yes, although I have no interest in making it easy for people to add > their own custom, non-standard extensions to RTSP. > > 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 matt at schuckmannacres.com Tue Sep 25 16:05:00 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Tue, 25 Sep 2012 16:05:00 -0700 Subject: [Live-devel] Setting an upper limit on ports available for RTP use Message-ID: <5062389C.1050705@schuckmannacres.com> Ross, As part of upgrading our version of LiveMedia I'm reminded of a modification that we put in our code and suggested to you but apparently never made it into the code. We put in a way to set an upper limit on the ports available for RTP/RTCP use. We did this for servers that are behind a NAT or firewall where only a limited number of ports are forwarded through to the server and we didn't want the server to assign ports outside that range. We simply added a number of ports parameter to RTSPServer and OnDemandServerMediaSubsession (where it's really used in getStreamParameters()). Do you think this feature could be added to the code? FYI in looking at the current code for OnDemandServerMediaSubsession::getStreamParameters() the 2 for loops that attempt get the next available port could loop indefinitely if no ports were available (I know unlikely but possible), implementing an upper bound on the port range could prevent this from happening. Thanks, Matt S. From kingaceck at 163.com Tue Sep 25 02:43:00 2012 From: kingaceck at 163.com (kingaceck) Date: Tue, 25 Sep 2012 17:43:00 +0800 Subject: [Live-devel] live555ProxyServer issue Message-ID: <201209251742479217701@163.com> hi I had asked: I use live555ProxyServer at the LAN,when more then two client connect to the server playing mp4 file(1080p h264 aac),there are many mosaic and the sound is off and on .If one client connect to the server it is ok.why? Your anwser is: Most likely, packet loss. You probably don't have sufficient network capacity to support this number of separate clients. I made a test of the network capacity :I use FTP to send the data,the network capacity is 5M/s at least. When the mosaic exists at the client I see the server send data at the speed of 2.5M/s.So I think the network doesn't arrive it's max capacity. I read the source and found the live555ProxyServer send data like this : Boolean Groupsock::output(UsageEnvironment& env, u_int8_t ttlToSend, unsigned char* buffer, unsigned bufferSize, DirectedNetInterface* interfaceNotToFwdBackTo) { do { // First, do the datagram send, to each destination: Boolean writeSuccess = True; for (destRecord* dests = fDests; dests != NULL; dests = dests->fNext) { if (!write(dests->fGroupEId.groupAddress().s_addr, dests->fPort, ttlToSend, buffer, bufferSize)) { writeSuccess = False; break; } } if (!writeSuccess) break; statsOutgoing.countPacket(bufferSize); statsGroupOutgoing.countPacket(bufferSize); ...... So I guess ,the more "dests",the more times this code need to excute. At the client I can grap the rtp packet .But when playing using vlc there are some message: main warning: picture is too late to be displayed (missing 600 ms) main warning: picture is too late to be displayed (missing 215 ms) main warning: picture is too late to be displayed (missing 135 ms) main warning: picture is too late to be displayed (missing 279 ms) main warning: picture is too late to be displayed (missing 199 ms) main error: pictures leaked, trying to workaround main error: pictures leaked, trying to workaround main error: pictures leaked, trying to workaround main error: pictures leaked, trying to workaround avcodec error: more than 5 seconds of late video -> dropping frame (computer too slow ?) main error: pictures leaked, trying to workaround ...... When the messages show,there are many mosaic exist on the video. I have two questions: (1) What's the probably reason of the mosaic ? (2) I want to relay the rtp packet directly (don't analysis the packet then packet it),what should I to do? Thank you very much. 2012-09-25 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 26 14:51:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Sep 2012 14:51:33 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: <50623290.9000703@schuckmannacres.com> References: <5060D798.8080903@schuckmannacres.com> <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> <50623290.9000703@schuckmannacres.com> Message-ID: <7ACA8583-BA4A-48F8-A865-7AA6B480CF79@live555.com> > While your at it I noticed that the member fDestinationsHashTable of OnDemandServerMediaSubsession is private while the class Destinations is declared in the header with a comment about it being accessible by subclasses. In addition many of the methods that interact with fDestinationsHashTable like getStreamParameters(), startStream(), endStream(), etc are all declared virtual implying that sub classes should have access to fDestinationsHashTable and it should be declared protected. No, the fact that a class's member function is declared virtual doesn't imply that all data structures that happen to be used by that member function's implementation in the base class should be made accessible by subclasses. There was never any intention to have "fDestinationsHashTable" be accessible by subclasses of "OnDemandServerMediaSubsession". (If you feel you need this, however, just let me know.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Wed Sep 26 15:09:57 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Wed, 26 Sep 2012 15:09:57 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: <7ACA8583-BA4A-48F8-A865-7AA6B480CF79@live555.com> References: <5060D798.8080903@schuckmannacres.com> <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> <50623290.9000703@schuckmannacres.com> <7ACA8583-BA4A-48F8-A865-7AA6B480CF79@live555.com> Message-ID: <50637D35.8040001@schuckmannacres.com> In looking at our old code we were looking at fDestinationsHashTable to determine if a stream was RTP over TCP or RTP over UDP (for a server sessions status widget). This was done before you put the StreamState and Destinations classes in the header and the guy that did it back then added a GetClientCommProtocol() method to OnDemandServerMediaSubsession that checked the isTCP member of the Destinations object for the sessionID . I wanted to do the same but without modifying your code so I was going to put it in a child class but I can't if fDestinationsHashTable is private. If there is another better way to determine if a session is TCP or UDP I'd be willing to go with that. Thanks, Matt S. On Wednesday, September 26, 2012 2:51:33 PM, Ross Finlayson wrote: >> While your at it I noticed that the member fDestinationsHashTable of >> OnDemandServerMediaSubsession is private while the class Destinations >> is declared in the header with a comment about it being accessible by >> subclasses. In addition many of the methods that interact with >> fDestinationsHashTable like getStreamParameters(), startStream(), >> endStream(), etc are all declared virtual implying that sub classes >> should have access to fDestinationsHashTable and it should be >> declared protected. > > No, the fact that a class's member function is declared virtual > doesn't imply that all data structures that happen to be used by that > member function's implementation in the base class should be made > accessible by subclasses. There was never any intention to have > "fDestinationsHashTable" be accessible by subclasses of > "OnDemandServerMediaSubsession". (If you feel you need this, however, > just let me know.) > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Wed Sep 26 20:04:38 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 26 Sep 2012 20:04:38 -0700 Subject: [Live-devel] Setting an upper limit on ports available for RTP use In-Reply-To: <5062389C.1050705@schuckmannacres.com> References: <5062389C.1050705@schuckmannacres.com> Message-ID: <7F759EFD-0DF3-4267-A897-6FCEC8200111@live555.com> > As part of upgrading our version of LiveMedia I'm reminded of a modification that we put in our code and suggested to you but apparently never made it into the code. > > We put in a way to set an upper limit on the ports available for RTP/RTCP use. We did this for servers that are behind a NAT or firewall where only a limited number of ports are forwarded through to the server and we didn't want the server to assign ports outside that range. > > We simply added a number of ports parameter to RTSPServer and OnDemandServerMediaSubsession (where it's really used in getStreamParameters()). > Do you think this feature could be added to the code? Mumble... Maybe, but I don't consider this a high-priority request, because it would make the server *less* functional. (If the server could only allocate port numbers that were outside your preferred range, then the stream would still be accessible if the client happened to be inside your firewall.) Also, just setting an upper limit on port numbers wouldn't be enough; I would also need to update the code to respond to the "SETUP" with an error response code if the server were unable to allocate port numbers in the desired range. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 27 07:06:08 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Sep 2012 07:06:08 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: <50637D35.8040001@schuckmannacres.com> References: <5060D798.8080903@schuckmannacres.com> <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> <50623290.9000703@schuckmannacres.com> <7ACA8583-BA4A-48F8-A865-7AA6B480CF79@live555.com> <50637D35.8040001@schuckmannacres.com> Message-ID: > In looking at our old code we were looking at fDestinationsHashTable to determine if a stream was RTP over TCP or RTP over UDP (for a server sessions status widget). > This was done before you put the StreamState and Destinations classes in the header and the guy that did it back then added a GetClientCommProtocol() method to OnDemandServerMediaSubsession that checked the isTCP member of the Destinations object for the sessionID . I wanted to do the same but without modifying your code so I was going to put it in a child class but I can't if fDestinationsHashTable is private. > > If there is another better way to determine if a session is TCP or UDP Yes - the way to do this is to inspect a "RTSPServer::RTSPClientSession" object, because that is the class that represents the state of a RTSP/RTP/RTCP stream to a client. Beginning with the latest release (version 2012.09.27) of the "LIVE555 Streaming Media" code, there's a member function Boolean usesTCPTransport(); of the "RTSPServer::RTSPClientSession" class that you can call, to check whether a stream is TCP or UDP. (If you need your own way to keep track of these "RTSPServer::RTSPClientSession" objects, then the way to do this is to: - Subclass "RTSPServer" and "RTSPServer::RTSPClientSession" - Redefine the virtual function "RTSPServer::createNewClientSession()", and reimplement it (in your "RTSPServer" subclass) to return an instance of your "RTSPServer::RTSPClientSession" subclass. - (Perhaps) Redefine and reimplement the destructor of your "RTSPServer::RTSPClientSession" subclass also. ) Note that, in contrast, an "OnDemandServerMediaSubsession" object is the *wrong* thing to be inspecting, because that class represents a piece of media that can be streamed, possibly several different times (sequentially or concurrently), to many different clients (which might have request TCP streaming, or UDP streaming). And a "StreamState" object is also the wrong thing to be inspecting, because that class represents the state of a currently ongoing stream (from the piece of media represented by an "OnDemandServerMediaSubsession" object), *possibly to several different concurrent clients* (if the "reuseFirstSource" parameter was set to True). In fact, I'm not convinced that any developer needs to have the "StreamState" class (or the "Destinations" class) visible, so there's a good chance that this visibility will be removed in future releases of the software. (So if you, or anyone, believes that they really need these classes to remain visible, then please let us know ASAP.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at sound4.biz Thu Sep 27 06:57:38 2012 From: eric at sound4.biz (Eric HEURTEL) Date: Thu, 27 Sep 2012 15:57:38 +0200 Subject: [Live-devel] RTSPClientSessions lifetime Message-ID: <50645B52.6070902@sound4.biz> Hi Ross and everybody, On Server side, RTSPClientSessions are created on SETUP when request does not specify a Session ID. It seems that there is no direct relation between a Connection and a Session. Is it because many Connections can share the same Session ? In this case I wonder when Sessions are closed and destroyed : is it when all Connections sharing a Session are closed ? Or is there a timeout somewhere ? Eric HEURTEL -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 27 07:12:52 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Sep 2012 07:12:52 -0700 Subject: [Live-devel] RTP timestamp issue after RTCP synchronization In-Reply-To: References: <6A656F06-E78E-45BA-8653-82F4D65BF782@live555.com> Message-ID: <63966103-5375-4C5A-ACD2-4BF33B0467FF@live555.com> FYI - the latest release (2012.09.27) of the "LIVE555 Streaming Media" software should fix this issue. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 27 07:32:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Sep 2012 07:32:15 -0700 Subject: [Live-devel] RTSPClientSessions lifetime In-Reply-To: <50645B52.6070902@sound4.biz> References: <50645B52.6070902@sound4.biz> Message-ID: <6ED51E1C-F6DF-4A9F-8E01-5221B78B68FC@live555.com> > On Server side, RTSPClientSessions are created on SETUP when request does not specify a Session ID. > It seems that there is no direct relation between a Connection and a Session. Is it because many Connections can share the same Session ? Yes. > In this case I wonder when Sessions are closed and destroyed : is it when all Connections sharing a Session are closed ? No, because another connection - for the same session - could be created next. > Or is there a timeout somewhere ? Yes. Note the following comment (in "liveMedia/include/RTSPServer.hh", lines 69-72: // If "reclamationTestSeconds" > 0, then the "RTSPClientSession" state for // each client will get reclaimed (and the corresponding RTP stream(s) // torn down) if no RTSP commands - or RTCP "RR" packets - from the // client are received in at least "reclamationTestSeconds" seconds. Note that standards-compliant RTSP/RTP clients are required to implement RTCP - thereby sending frequent RTCP "RR" packets to indicate client liveness. (If the clients are implemented using our software, then they will get this automatically.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Thu Sep 27 09:32:21 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Thu, 27 Sep 2012 09:32:21 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: References: <5060D798.8080903@schuckmannacres.com> <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> <50623290.9000703@schuckmannacres.com> <7ACA8583-BA4A-48F8-A865-7AA6B480CF79@live555.com> <50637D35.8040001@schuckmannacres.com> Message-ID: <50647F95.2000209@schuckmannacres.com> On 9/27/2012 7:06 AM, Ross Finlayson wrote: > Note that, in contrast, an "OnDemandServerMediaSubsession" object is > the *wrong* thing to be inspecting, because that class represents a > piece of media that can be streamed, possibly several different times > (sequentially or concurrently), to many different clients (which might > have request TCP streaming, or UDP streaming). > > And a "StreamState" object is also the wrong thing to be inspecting, > because that class represents the state of a currently ongoing stream > (from the piece of media represented by > an "OnDemandServerMediaSubsession" object), *possibly to several > different concurrent clients* (if the "reuseFirstSource" parameter was > set to True). > > In fact, I'm not convinced that any developer needs to have the > "StreamState" class (or the "Destinations" class) visible, so there's > a good chance that this visibility will be removed in future releases > of the software. (So if you, or anyone, believes that they really > need these classes to remain visible, then please let us know ASAP.) > For an example, our sever session status widget displays, among other things the RTP and RTCP ports for UDP that are in use for each stream in each client session. Right or wrong the way we did it before was by sub-classing RTSPClientSession so we'd have access to the void* streamToken for each stream and then through OnDemaindMediaSubsession (or a subclass there of) inspecting the values in the StreamState object. Each RTSPClientSession object has a list of StreamState objects that appears to hold all of this kind of information and it appears to be specific to the client session. Looking at OnDemandServerMediaSubsession::getStreamParameters() it looks like the StreamState and Destinations objects do get shared if fReuseFirstSource is true otherwise a new set of each gets created for each client session. In our case fReuseFirstSource is never true so any sharing have states has never been a problem. I'm not quite sure how it works if fReuseFirstSource is set and one client requests a TCP connection and another a UDP? Spending a few minutes looking at the code this morning I can't see another easy way to do this. In looking at the change log, in June of last year you intentionally moved the definition of StreamState to OnDemandServerMediaSubsession.hh so that subclasses of OnDemandServerMediaSubsession could access them. I remember when you did this and I thought it was due to a specific request from the mailing list but I can't find the thread now. Matt S. > > 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 matt at schuckmannacres.com Thu Sep 27 10:29:23 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Thu, 27 Sep 2012 10:29:23 -0700 Subject: [Live-devel] Setting an upper limit on ports available for RTP use In-Reply-To: <7F759EFD-0DF3-4267-A897-6FCEC8200111@live555.com> References: <5062389C.1050705@schuckmannacres.com> <7F759EFD-0DF3-4267-A897-6FCEC8200111@live555.com> Message-ID: <50648CF3.3010207@schuckmannacres.com> On Wednesday, September 26, 2012 8:04:38 PM, Ross Finlayson wrote: >> As part of upgrading our version of LiveMedia I'm reminded of a >> modification that we put in our code and suggested to you but >> apparently never made it into the code. >> >> We put in a way to set an upper limit on the ports available for >> RTP/RTCP use. We did this for servers that are behind a NAT or >> firewall where only a limited number of ports are forwarded through >> to the server and we didn't want the server to assign ports outside >> that range. >> >> We simply added a number of ports parameter to RTSPServer and >> OnDemandServerMediaSubsession (where it's really used in >> getStreamParameters()). >> Do you think this feature could be added to the code? > > Mumble... Maybe, but I don't consider this a high-priority request, > because it would make the server *less* functional. (If the server > could only allocate port numbers that were outside your preferred > range, then the stream would still be accessible if the client > happened to be inside your firewall.) Also, just setting an upper > limit on port numbers wouldn't be enough; I would also need to update > the code to respond to the "SETUP" with an error response code if the > server were unable to allocate port numbers in the desired range. I'm not so sure about the less functional statement, if I'm setting up a server with this feature then I have good reasons for it and I probably don't care if a client inside a firewall could access the server on a port outside of my specified range, probably because I don't intended to have any clients inside the firewall. With regards to needing to respond to the SETUP with a response code, I would argue that you need this regardless if you add this feature or not. Currently if no ports are available getStreamParameters() will loop infinitely, even though it's unlikely to happen it's still bad design. If you really don't want to add a response code on failure I'd be happy with just looping through he specified range of ports until an available pair of ports are found. Another alternative is to break up getStreamParameters() with some sort of virtual method to get the next port to try or a method to create the groupsock, so that subclasses can implement there own algorithm for obtaining ports. Thanks, Matt S. > > > 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 matt at schuckmannacres.com Thu Sep 27 11:17:07 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Thu, 27 Sep 2012 11:17:07 -0700 Subject: [Live-devel] RTP timestamp issue after RTCP synchronization In-Reply-To: <63966103-5375-4C5A-ACD2-4BF33B0467FF@live555.com> References: <6A656F06-E78E-45BA-8653-82F4D65BF782@live555.com> <63966103-5375-4C5A-ACD2-4BF33B0467FF@live555.com> Message-ID: <50649823.9070807@schuckmannacres.com> Hi, I noticed that you updated the changelog for this release but the release has not been posted. Is this an oversight or are you still working on testing, etc? Thanks, Matt S. On Thursday, September 27, 2012 7:12:52 AM, Ross Finlayson wrote: > FYI - the latest release (2012.09.27) of the "LIVE555 Streaming Media" > software should fix this issue. > > 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 Thu Sep 27 12:06:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Sep 2012 12:06:05 -0700 Subject: [Live-devel] RTP timestamp issue after RTCP synchronization In-Reply-To: <50649823.9070807@schuckmannacres.com> References: <6A656F06-E78E-45BA-8653-82F4D65BF782@live555.com> <63966103-5375-4C5A-ACD2-4BF33B0467FF@live555.com> <50649823.9070807@schuckmannacres.com> Message-ID: <373A7EE8-742D-40B5-A1EF-0089D7C27A17@live555.com> > I noticed that you updated the changelog for this release but the release has not been posted. Sorry - my mistake. It's up now. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Thu Sep 27 13:02:41 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Thu, 27 Sep 2012 20:02:41 +0000 Subject: [Live-devel] Client connection timeout Message-ID: When connecting to a server that doesn't respond, or is just slow, the timeout appears to be around 25s, i.e. the time before the response handler is called. Is there a way to decrease this time? Why? Well, in the project I'm working on there are lots of changing cameras that are on a 10s cycle, so there is no need to try for more than 10s. While I assume it should be ok to call shutdown() while the client is still trying (and stop the event loop etc), it would be beneficial to be able to wait for the response handler to return. I've seen some lingering connections in rare cases, which most likely is due to my code, but it would nonetheless be nicer to always wait for the response handler. These yet unexplained lingering connections happens for maybe 1 stream out of 20000. When looking in the code the only somewhat related variable or function I see is the sessionTimeoutParameter which doesn't seem to have anything with the connection timeout to do. Two testRTSPClient examples below. In the first I just connect to an arbitrary URL where there is no server that responds, and it takes about 25s before the response handler is called. In the second example our Cisco VSM is bogged down and it takes 30s for it to respond. e:\projects\live\Release>testRTSPClient.exe rtsp://ibm.com/moo !!! fInputSocketNum -1 Opening connection to 129.42.38.1, port 554... !!! connectResult 0 ...Connection to server failed: Unknown error [URL:"rtsp://ibm.com/moo"]: Failed to get a SDP description: Connection to server failed: Unknown error [URL:"rtsp://ibm.com/moo"]: Closing the stream. e:\projects\live\Release>testRTSPClient.exe rtsp://192.168.1.103/live/TVF-16 !!! fInputSocketNum -1 Opening connection to 192.168.1.103, port 554... !!! connectResult 0 ...remote connection opened !!! fInputSocketNum 124 Sending request: DESCRIBE rtsp://192.168.1.103/live/TVF-16 RTSP/1.0 CSeq: 2 User-Agent: testRTSPClient.exe (LIVE555 Streaming Media v2012.09.13) Accept: application/sdp Received 61 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 500 Server Error (Unable to open proxy) CSeq: 2 [URL:"rtsp://192.168.1.103/live/TVF-16"]: Failed to get a SDP description: 500 Server Error (Unable to open proxy) [URL:"rtsp://192.168.1.103/live/TVF-16"]: Closing the stream. /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Thu Sep 27 14:07:50 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Sep 2012 14:07:50 -0700 Subject: [Live-devel] Client connection timeout In-Reply-To: References: Message-ID: <816D48CB-FA80-4E36-BD2B-895A90CE13CB@live555.com> > When connecting to a server that doesn't respond, or is just slow, the timeout appears to be around 25s, i.e. the time before the response handler is called. That timeout is inside the operating system (i.e., the OS's TCP/IP implementation). It's not in our code at all/ > Is there a way to decrease this time? Not in our code, but perhaps there might be a way to configure your OS to reduce it?? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 28 01:33:39 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Sep 2012 01:33:39 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: <50647F95.2000209@schuckmannacres.com> References: <5060D798.8080903@schuckmannacres.com> <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> <50623290.9000703@schuckmannacres.com> <7ACA8583-BA4A-48F8-A865-7AA6B480CF79@live555.com> <50637D35.8040001@schuckmannacres.com> <50647F95.2000209@schuckmannacres.com> Message-ID: > For an example, our sever session status widget displays, among other things the RTP and RTCP ports for UDP that are in use for each stream in each client session. Right or wrong the way we did it before was by sub-classing RTSPClientSession so we'd have access to the void* streamToken for each stream and then through OnDemaindMediaSubsession (or a subclass there of) inspecting the values in the StreamState object. Each RTSPClientSession object has a list of StreamState objects that appears to hold all of this kind of information and it appears to be specific to the client session. [...] > Spending a few minutes looking at the code this morning I can't see another easy way to do this. Another way to do this - which is the way that I originally would have preferred - is to redefine (in your "OnDemandServerMediaSubsession" subclass) the "getStreamParameters()" virtual function. Your reimplemented "getStreamParameters()" would first call the original "getStreamParameters()", and then get the RTP and RTCP port numbers (which were result parameters from this call). But on reflection this probably isn't really any cleaner than what you're doing, so, reluctantly, I'll endorse letting developers see the "StreamState" and "Destinations" classes. So, in the next release of the software, I'll make the "fDestinationsHashTable" field "protected:". That should give you what you need. > I'm not quite sure how it works if fReuseFirstSource is set and one client requests a TCP connection and another a UDP? Aha! There's actually a bug in the current code that prevents this from working properly. That's another thing that I'll need to fix in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Fri Sep 28 05:43:18 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Fri, 28 Sep 2012 20:43:18 +0800 Subject: [Live-devel] Regarding the audio and video packet sent rate Message-ID: <006d01cd9d76$d6d557a0$848006e0$@126.com> Hi, I use live555 send the audio and video packet as soon as possible. but the video and audio encoding rate isn't same. so the video and audio packet vlc receives isn't synchro. So I tried to adjust the video and audio send rate, but I can't get the balance. I always get the error "pts is out of range" or "the received buffer is in future". Does live555 have mechanism to balance it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 28 07:17:54 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Sep 2012 07:17:54 -0700 Subject: [Live-devel] Regarding the audio and video packet sent rate In-Reply-To: <006d01cd9d76$d6d557a0$848006e0$@126.com> References: <006d01cd9d76$d6d557a0$848006e0$@126.com> Message-ID: <783A15CD-FAC5-458B-9DD1-90065C1811C9@live555.com> > I use live555 send the audio and video packet as soon as possible. > but the video and audio encoding rate isn't same. so the video and audio packet vlc receives isn't synchro. > So I tried to adjust the video and audio send rate, but I can't get the balance. I always get the error "pts is out of range" or "the received buffer is in future". > Does live555 have mechanism to balance it? Once again, you are probably not setting "fPresentationTime" correctly for both audio and video streams. In the code that you noted in one of your earlier messages, there was a bug: fDurationInMicroseconds = 5000; // because 40 samples at 8000 samples-per-second have a duration of 5 ms (== 5000 us) That line of code is correct for audio (because each outgoing audio packet contains 40 samples). However, you used the exact same line for video, which is wrong (because your video frame rate is (presumably) *not* also 200 frames-per-second). For video, you need to set a correct value of "fDurationInMicroseconds" that corresponds to your video frame rate. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Fri Sep 28 03:25:48 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Fri, 28 Sep 2012 18:25:48 +0800 Subject: [Live-devel] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIHN1cHBvcnQgYmxhY2tt?= =?gb2312?b?YWdpYyBjYXJk?= Message-ID: <005a01cd9d63$a1a60e70$e4f22b50$@126.com> Oh, sorry, I make a mistake on the recipient. ???: ????? [mailto:fantasyvideo at 126.com] ????: 2012?9?28? 18:22 ???: 'live-devel at ns.live555.com' ??: Regarding support blackmagic card Hi, I saw some code about blackmagic in live555. So is it possible I can setup one rtsp server which is based on blackmagic directly, but not get the video and audio data, then provide them to live555? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruno.Marchand at averna.com Fri Sep 28 09:55:36 2012 From: Bruno.Marchand at averna.com (Bruno Marchand) Date: Fri, 28 Sep 2012 12:55:36 -0400 Subject: [Live-devel] RTP timestamp issue after RTCP synchronization In-Reply-To: <63966103-5375-4C5A-ACD2-4BF33B0467FF@live555.com> References: <6A656F06-E78E-45BA-8653-82F4D65BF782@live555.com> <63966103-5375-4C5A-ACD2-4BF33B0467FF@live555.com> Message-ID: Hi Ross, Thank you very much for the fix. This new release fixes the problem I had with the camera date and time. Regards, Bruno Marchand -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 28 14:04:43 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Sep 2012 14:04:43 -0700 Subject: [Live-devel] Setting Multiple Parameters with one SET_PARAMETER command In-Reply-To: References: <5060D798.8080903@schuckmannacres.com> <1B1B5523-D5BA-4047-86C2-D99A89063C7D@live555.com> <50623290.9000703@schuckmannacres.com> <7ACA8583-BA4A-48F8-A865-7AA6B480CF79@live555.com> <50637D35.8040001@schuckmannacres.com> <50647F95.2000209@schuckmannacres.com> Message-ID: <8ED913A9-BA64-4D3A-9795-E7387E08E0DD@live555.com> >> I'm not quite sure how it works if fReuseFirstSource is set and one client requests a TCP connection and another a UDP? > > Aha! There's actually a bug in the current code that prevents this from working properly. It turns out that I was mistaken about this. The current code handles this situation correctly, I think. (If "fReuseFirstSource" is set, then each client's connection will use the same "StreamState" object, but with different "Destinations" objects. Everything should work OK...) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xzha286 at aucklanduni.ac.nz Sat Sep 29 00:25:07 2012 From: xzha286 at aucklanduni.ac.nz (James Zhang) Date: Sat, 29 Sep 2012 07:25:07 +0000 (UTC) Subject: [Live-devel] Invitation to connect on LinkedIn Message-ID: <339511402.2495272.1348903507332.JavaMail.app@ela4-app2313.prod> LinkedIn ------------ LIVE555, I'd like to add you to my professional network on LinkedIn. - James James Zhang Attended University of Auckland New Zealand Confirm that you know James Zhang: https://www.linkedin.com/e/-xmp4a0-h7oebjhi-2y/isd/8864196220/GlZdzT_Q/?hs=false&tok=3QV96GwxUZ2Rs1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-xmp4a0-h7oebjhi-2y/LWRhw-_VQYm3Ha_FCogvNM42mY81Q03zM1UVaKE/goo/live-devel%40ns%2Elive555%2Ecom/20061/I2976711668_1/?hs=false&tok=3BNRfL4cgZ2Rs1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Sep 29 00:33:32 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Sep 2012 00:33:32 -0700 Subject: [Live-devel] Invitation to connect on LinkedIn In-Reply-To: <339511402.2495272.1348903507332.JavaMail.app@ela4-app2313.prod> References: <339511402.2495272.1348903507332.JavaMail.app@ela4-app2313.prod> Message-ID: <5B8CAEB8-4291-4CEB-ADD7-8349620C455F@live555.com> Grrr! All future postings to the list from this clown will be moderated. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From qiuchangyong at gmail.com Fri Sep 28 19:52:10 2012 From: qiuchangyong at gmail.com (qiuchangyong qiuchangyong) Date: Sat, 29 Sep 2012 10:52:10 +0800 Subject: [Live-devel] report a bug of openRTSP In-Reply-To: <7957C35F-6D0D-4801-A5EC-68140A418A5F@live555.com> References: <7957C35F-6D0D-4801-A5EC-68140A418A5F@live555.com> Message-ID: Hi Ross, Thanks for your advice of redirecting stdout to a file, it works, and I find the issue that dumped avi file cannot play in windows media player, that's because the avi file has no index in the end. Now I make some changes by add the index to the file after written movi data. i enclose the two changed files, but the changed code maybe uglily written, hope it be changed gracefully. 2012/9/8 Ross Finlayson > I try to use openRTSP to dump the rtsp stream to AVI file with command > like this "openRTSP -i w 352 -h 288 -f 25 rtsp://xxxx", where xxxx is the > real rtsp url, I've also change the code of "playCommon.cpp" in the line : > *aviOut = AVIFileSink::createNew(*env, *session, "stdout",* > to *aviOut = AVIFileSink::createNew(*env, *session, "openRTSP.avi"* > > > You don't need to do this. Instead, just do > openRTSP -i w 352 -h 288 -f 25 rtsp://xxxx > openRTSP.avi > i.e., redirect 'stdout' to a file on the command line. > > > i can get the file, but it couldnot play, then i check the content of > openRTSP.avi file, find that the h264 start code is missing(the video codec > from stream is avc"). > so i add something to AVIFileSink.cpp, useFrame, like this > > > Thanks. I will include this change in the next version 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AVIFileSink.cpp Type: text/x-c++src Size: 26981 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AVIFileSink.hh Type: application/octet-stream Size: 3974 bytes Desc: not available URL: From finlayson at live555.com Sat Sep 29 08:53:29 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Sep 2012 08:53:29 -0700 Subject: [Live-devel] report a bug of openRTSP In-Reply-To: References: <7957C35F-6D0D-4801-A5EC-68140A418A5F@live555.com> Message-ID: <9A3A1FD8-143B-4B62-98D0-17602602693A@live555.com> > Thanks for your advice of redirecting stdout to a file, it works, and I find the issue that dumped avi file cannot play in windows media player, that's because the avi file has no index in the end. Now I make some changes by add the index to the file after written movi data. > i enclose the two changed files, but the changed code maybe uglily written, hope it be changed gracefully. Thanks. I'll be adding this change to some future release of the library. (We don't use the STL, however, in case there are developers out there who either don't have the STL available, or (more likely) have it, but don't want to use it (e.g., because they are developing for a resource-constrained system).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Fri Sep 28 22:38:51 2012 From: kingaceck at 163.com (kingaceck) Date: Sat, 29 Sep 2012 13:38:51 +0800 Subject: [Live-devel] relay the audio and video that coming from two ports Message-ID: <201209291338471711688@163.com> Hi I know that the testRelay program repeatedly reads from a UDP socket, and retransmits each packet's payload to a new (multicast or unicast) address and port. The data reading from the UDP socket contains audio and video data. Now I want to relay the RTSP consists of an audio and a video subsession.The RTSP sends audio and video data to the diffrent port,But the testRelay program can read data only from one port.What can I to do to relay the audio and video that coming from two ports. Thank you very much. 2012-09-29 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Fri Sep 28 22:44:05 2012 From: kingaceck at 163.com (kingaceck) Date: Sat, 29 Sep 2012 13:44:05 +0800 Subject: [Live-devel] relay the audio and video that coming from two ports(2) Message-ID: <201209291343599534211@163.com> Sorry I forgot to say I relay the audio and video coming from two ports using multicast. 2012-09-29 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Sep 29 13:10:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Sep 2012 13:10:59 -0700 Subject: [Live-devel] relay the audio and video that coming from two ports In-Reply-To: <201209291338471711688@163.com> References: <201209291338471711688@163.com> Message-ID: > I know that the testRelay program repeatedly reads from a UDP socket, and retransmits each packet's payload to a new (multicast or unicast) address and port. The data reading from the UDP socket contains audio and video data. Now I want to relay the RTSP consists of an audio and a video subsession.The RTSP sends audio and video data to the diffrent port,But the testRelay program can read data only from one port.What can I to do to relay the audio and video that coming from two ports. It's easy. Simply model your application on the existing "testRelay" code, but duplicate the code that creates source and sink objects, and calls "startPlaying()". I.e., - Create another "groupsock" object: "inputGroupsock2" - From this, create another "FramedSource*": "source2" - Create another "groupsock" object: "outputGroupsock2" - From this, create another "MediaSink*": "sink2" - Then call sink2->startPlaying(*source2, NULL, NULL); This call can be before or after the original sink->startPlaying(*source, NULL, NULL); but both must occur before the call to env->taskScheduler().doEventLoop(); Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From easymob at gmail.com Sat Sep 29 00:32:12 2012 From: easymob at gmail.com (easymob) Date: Sat, 29 Sep 2012 15:32:12 +0800 Subject: [Live-devel] memory leak when use rtspclient with over-tcp option Message-ID: I found a memory leak when use rtspclient with over-tcp option, if not use over-tcp it's OK! Detected memory leaks! Dumping objects -> c:\program files\microsoft visual studio 9.0\vc\include\crtdbg.h(1203) : {638} normal block at 0x01C55988, 48 bytes long. Data: 70 23 56 00 90 59 C5 01 00 00 00 00 00 00 00 00 c:\program files\microsoft visual studio 9.0\vc\include\crtdbg.h(1203) : {59} normal block at 0x006F3F60, 16 bytes long. Data: < T Y o > BC D8 54 00 00 00 00 00 88 59 C5 01 18 17 6F 00 c:\program files\microsoft visual studio 9.0\vc\include\crtdbg.h(1203) : {57} normal block at 0x006F1718, 1024 bytes long. Data: < T `?o o > 9C AE 54 00 60 3F 6F 00 00 00 00 00 90 12 6F 00 Object dump complete. ===================================== ZhangJun MSN:ejc33 at hotmail.com QQ:15142845 ===================================== From fantasyvideo at 126.com Sat Sep 29 04:52:26 2012 From: fantasyvideo at 126.com (=?gb2312?B?w867w7mk1/fK0g==?=) Date: Sat, 29 Sep 2012 19:52:26 +0800 Subject: [Live-devel] =?gb2312?b?tPC4tDogIFJlZ2FyZGluZyB0aGUgYXVkaW8gYW5k?= =?gb2312?b?IHZpZGVvIHBhY2tldCBzZW50IHJhdGU=?= In-Reply-To: <783A15CD-FAC5-458B-9DD1-90065C1811C9@live555.com> References: <006d01cd9d76$d6d557a0$848006e0$@126.com> <783A15CD-FAC5-458B-9DD1-90065C1811C9@live555.com> Message-ID: <000001cd9e38$e6a172f0$b3e458d0$@126.com> Thanks for your patient. Now I adjust the settings. Since I collect the data from one card, then convert them to g711 and h264. My card?s raw video:50fps. Raw audio: 48000hz,16bits, 2channel. Then I convert audio to be g711 8000hz,8bit, 1channel. Video is still 50fps. At last the duration of video and audio are all 20000us, and I call newTask()=envir().taskScheduler().scheduleDelayedTask(20000,(TaskFunc*)Frame dSource::aftergetting,this) in the doGetNextFrame(). So in such case, my fPresentationTime should be correct. But I don?t know why the vlc said ?early picture skipped?, it seems that shows my video frame is old. ???: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] ?? Ross Finlayson ????: 2012?9?28? 22:18 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] Regarding the audio and video packet sent rate I use live555 send the audio and video packet as soon as possible. but the video and audio encoding rate isn't same. so the video and audio packet vlc receives isn't synchro. So I tried to adjust the video and audio send rate, but I can't get the balance. I always get the error "pts is out of range" or "the received buffer is in future". Does live555 have mechanism to balance it? Once again, you are probably not setting "fPresentationTime" correctly for both audio and video streams. In the code that you noted in one of your earlier messages, there was a bug: fDurationInMicroseconds = 5000; // because 40 samples at 8000 samples-per-second have a duration of 5 ms (== 5000 us) That line of code is correct for audio (because each outgoing audio packet contains 40 samples). However, you used the exact same line for video, which is wrong (because your video frame rate is (presumably) *not* also 200 frames-per-second). For video, you need to set a correct value of "fDurationInMicroseconds" that corresponds to your video frame rate. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: