From ccaughie at openeye.net Mon Apr 1 16:31:36 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Mon, 1 Apr 2013 16:31:36 -0700 Subject: [Live-devel] [PATCH] Provide access to the full time mapping in the last received sender report Message-ID: <853C62832D606043A043BD770304786C041DF353@EDD.pcopen.net> The attached patch allows access to the last received sender report RTP timestamp, making it possible to get the full NTP/RTP time mapping currently in effect (since it was already possible to get the last received NTP timestamp). This information can be used to calculate the wallclock timestamp of each sample in a live stream sent by an IP camera, according to the camera's clock. It probably isn't terribly useful in a non-live scenario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sraccess.patch Type: application/octet-stream Size: 2192 bytes Desc: sraccess.patch URL: From ccaughie at openeye.net Mon Apr 1 16:45:33 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Mon, 1 Apr 2013 16:45:33 -0700 Subject: [Live-devel] [PATCH] Improve efficiency of interleaved transport when one or more streams are being ignored Message-ID: <853C62832D606043A043BD770304786C041DF35E@EDD.pcopen.net> When an application is receiving data on some but not all of the streams in an interleaved RTSP session (i.e. it isn't calling getNextFrame() for some of the streams), the streams that are not being received consume an enormous amount of CPU cycles compared to the streams that are being processed. This is because the RTPInterface code reads the data one byte at a time, returning to the select() loop after each byte. This patch largely eliminates the problem by only returning to the select loop once all data currently in the socket buffer has been consumed (or after 2000 reads to avoid starvation). It could probably be made more efficient still by reading more than one byte at a time, but this approach involved the least amount of change to the existing code. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tcploop.patch Type: application/octet-stream Size: 4179 bytes Desc: tcploop.patch URL: From finlayson at live555.com Mon Apr 1 16:52:14 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Apr 2013 16:52:14 -0700 Subject: [Live-devel] [PATCH] Provide access to the full time mapping in the last received sender report In-Reply-To: <853C62832D606043A043BD770304786C041DF353@EDD.pcopen.net> References: <853C62832D606043A043BD770304786C041DF353@EDD.pcopen.net> Message-ID: > The attached patch allows access to the last received sender report RTP timestamp, making it possible to get the full NTP/RTP time mapping currently in effect (since it was already possible to get the last received NTP timestamp). > > This information can be used to calculate the wallclock timestamp of each sample in a live stream sent by an IP camera, according to the camera?s clock. I think you may not realize that our software already does this automatically! Whenever each frame of data is received (from a "RTPSource" subclass), then the "presentationTime" value will automatically get set to the value calculated from RTCP's 'RTP timestamp-to-NTP' mapping, as long as it has received at least one RTCP "SR" packet. In other words, receiving application software should never need to look at RTP timestamps (or RTCP-reported NTP times) directly. Instead, it just needs to look at the "presentation time" values for each received frame. For more information see http://www.live555.com/liveMedia/faq.html#separate-rtp-streams and http://www.live555.com/liveMedia/faq.html#rtcp-synchronization-issue (Therefore, I won't be applying your patch, unless you can demonstrate a clear need for it.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccaughie at openeye.net Mon Apr 1 16:56:30 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Mon, 1 Apr 2013 16:56:30 -0700 Subject: [Live-devel] [PATCH] Improve efficiency of interleaved transportwhen one or more streams are being ignored Message-ID: <853C62832D606043A043BD770304786C041DF364@EDD.pcopen.net> My apologies, I accidentally left in an unused variable declaration that I was using for debug purposes. Amended patch attached. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Colin Caughie Sent: Monday, April 01, 2013 4:46 PM To: live-devel at ns.live555.com Subject: [Live-devel] [PATCH] Improve efficiency of interleaved transportwhen one or more streams are being ignored When an application is receiving data on some but not all of the streams in an interleaved RTSP session (i.e. it isn't calling getNextFrame() for some of the streams), the streams that are not being received consume an enormous amount of CPU cycles compared to the streams that are being processed. This is because the RTPInterface code reads the data one byte at a time, returning to the select() loop after each byte. This patch largely eliminates the problem by only returning to the select loop once all data currently in the socket buffer has been consumed (or after 2000 reads to avoid starvation). It could probably be made more efficient still by reading more than one byte at a time, but this approach involved the least amount of change to the existing code. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tcploop.patch Type: application/octet-stream Size: 3755 bytes Desc: tcploop.patch URL: From finlayson at live555.com Mon Apr 1 21:47:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Apr 2013 21:47:06 -0700 Subject: [Live-devel] [PATCH] Improve efficiency of interleaved transportwhen one or more streams are being ignored In-Reply-To: <853C62832D606043A043BD770304786C041DF364@EDD.pcopen.net> References: <853C62832D606043A043BD770304786C041DF364@EDD.pcopen.net> Message-ID: <6BEB2137-4E3C-4C99-B264-D067BB40EBCD@live555.com> Thanks for the suggestion. I'll likely make this optimization (or something like it) in a future release of the software, though I first need to think through it a bit, to make sure there are no unforeseen consequences of not returning to the event loop after each byte read. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccaughie at openeye.net Mon Apr 1 22:01:06 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Mon, 1 Apr 2013 22:01:06 -0700 Subject: [Live-devel] [PATCH] Provide access to the full time mapping inthe last received sender report In-Reply-To: References: <853C62832D606043A043BD770304786C041DF353@EDD.pcopen.net> Message-ID: <853C62832D606043A043BD770304786C041DF382@EDD.pcopen.net> Thanks for the reply. I actually made that change about a year ago; I was aware that the code was already calculating presentation time for the purpose of synchronization, but for some reason I thought it was just a relative presentation time, not an absolute one that accurately reflected the time of frame capture. Looking at the code now though I'm not sure why I came to that conclusion as it definitely looks like it's doing the right thing. In which case please disregard my patch. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, April 01, 2013 4:52 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] [PATCH] Provide access to the full time mapping inthe last received sender report The attached patch allows access to the last received sender report RTP timestamp, making it possible to get the full NTP/RTP time mapping currently in effect (since it was already possible to get the last received NTP timestamp). This information can be used to calculate the wallclock timestamp of each sample in a live stream sent by an IP camera, according to the camera's clock. I think you may not realize that our software already does this automatically! Whenever each frame of data is received (from a "RTPSource" subclass), then the "presentationTime" value will automatically get set to the value calculated from RTCP's 'RTP timestamp-to-NTP' mapping, as long as it has received at least one RTCP "SR" packet. In other words, receiving application software should never need to look at RTP timestamps (or RTCP-reported NTP times) directly. Instead, it just needs to look at the "presentation time" values for each received frame. For more information see http://www.live555.com/liveMedia/faq.html#separate-rtp-streams and http://www.live555.com/liveMedia/faq.html#rtcp-synchronization-issue (Therefore, I won't be applying your patch, unless you can demonstrate a clear need for it.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccaughie at openeye.net Mon Apr 1 22:02:55 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Mon, 1 Apr 2013 22:02:55 -0700 Subject: [Live-devel] [PATCH] Improve efficiency of interleavedtransportwhen one or more streams are being ignored In-Reply-To: <6BEB2137-4E3C-4C99-B264-D067BB40EBCD@live555.com> References: <853C62832D606043A043BD770304786C041DF364@EDD.pcopen.net> <6BEB2137-4E3C-4C99-B264-D067BB40EBCD@live555.com> Message-ID: <853C62832D606043A043BD770304786C041DF383@EDD.pcopen.net> Thanks - in the meantime the change will be getting plenty of testing here; I'll let you know if we experience any problems with it. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, April 01, 2013 9:47 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] [PATCH] Improve efficiency of interleavedtransportwhen one or more streams are being ignored Thanks for the suggestion. I'll likely make this optimization (or something like it) in a future release of the software, though I first need to think through it a bit, to make sure there are no unforeseen consequences of not returning to the event loop after each byte read. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 842598566 at qq.com Mon Apr 1 17:58:48 2013 From: 842598566 at qq.com (=?ISO-8859-1?B?YWxpYXM=?=) Date: Tue, 2 Apr 2013 08:58:48 +0800 Subject: [Live-devel] (no subject) Message-ID: How do i modify live555ProxyServer so i can create a new session whenever a client asks for getting proxy stream comes from new sources (just like live555MediaServer open a different file and offer this stream when it received a new client'ack) normly the proxyserver only links one or more stream sources when it starts up, and we can't modify these stream sources while it's running) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Tue Apr 2 04:55:34 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Tue, 2 Apr 2013 12:55:34 +0100 Subject: [Live-devel] OutPacketBuffer::maxSize should be larger by default? Message-ID: Hey, Every camera I use these days seems to exceed the default OutPacketBuffer::maxSize by quite a large margin, e.g. MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too large for our buffer size (60804). 116669 bytes of trailing data was dropped! Correct this by increasing "OutPacketBuffer::maxSize" to at least 176669, *before* creating this 'RTPSink'. (Current value is 60000.) Is there any reason this buffer is so small by default? The buffers seem to be very small across the board, e.g. ./testProgs/testRTSPClient rtsp://86.146.236.49/media/video1 Outputs: MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 37417 bytes of trailing data will be dropped! Maybe the default should be at least 200000 to accommodate 720P and 1080P cameras these days? Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 2 17:24:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Apr 2013 17:24:46 -0700 Subject: [Live-devel] (no subject) In-Reply-To: References: Message-ID: > How do i modify live555ProxyServer so i can create a new session whenever a client asks for getting proxy stream comes from new sources > (just like live555MediaServer open a different file and offer this stream when it received a new client'ack) You would need to do something similar to what the "LIVE555 Media Server" code does: Define a subclass of "RTSPServer" and redefine (and reimplement) the "lookupServerMediaSession()" virtual function. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 2 18:01:40 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Apr 2013 18:01:40 -0700 Subject: [Live-devel] OutPacketBuffer::maxSize should be larger by default? In-Reply-To: References: Message-ID: <59898EC5-16B4-463C-B644-2F578FAD5794@live555.com> > Is there any reason this buffer is so small by default? This value is not 'small'. On the contrary - it's your cameras that are generating ridiculously 'large' frames :-) "OutPacketBuffer::maxSize" defines the largest possible 'frame' that a server (or a proxy server) can send. It's important to understand that each outgoing frame - if it is larger than the RTP/UDP packet size (about 1500 bytes on most networks) - will be broken up into multiple outgoing RTP packets, and the receiver must receive *all* of these packets in order to be able to reconstruct the frame. In other words, if even one of these packets is lost, then the receiver will lose the *entire* frame. The default 60000 byte size corresponds to a sequence of about *20* RTP/UDP packets (assuming a standard ~1500 byte MTU). Internet streaming servers should not be generating frames that are this large. But if they do, it's useful to have our code print out an error message, telling them that they're doing something that they shouldn't. (Ditto if you're trying to proxy frames this large; this will not work if the network in front of the proxy server has any significant packet loss. But if these networks happen to have no packet loss, then you can easily update your code to increase "OutPacketBuffer::maxSize".) I might end up increasing the default "OutPacketBuffer::maxSize" to 65000 kBytes (because such a frame would be large enough to fit inside a single 65536-byte UDP packet - the largest possible). But I'm not going to make the default size larger than this, because developers need to be aware of the consequences of having their servers (try to) transmit ridiculously large frames. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jesse.Hemingway at nerdery.com Tue Apr 2 15:18:35 2013 From: Jesse.Hemingway at nerdery.com (Jesse Hemingway) Date: Tue, 2 Apr 2013 17:18:35 -0500 Subject: [Live-devel] Getting server wallcock Message-ID: I had been going under the assumption that I could interpret the presentation times in terms of the server's wallclock. I just realized that, in fact, presentation time appears to have been converted to the client's local time, i.e. accounting for time zone, etc. Is this the case, and if so, is there any way to determine the server's actual wallclock time? I realize this may be deemed an overly-literal interpretation of presentation time, but it's actually extremely accurate if you happen to the in the same locality as the server. I apologize if this has been answered already. -Jesse -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 3 00:01:49 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Apr 2013 00:01:49 -0700 Subject: [Live-devel] Getting server wallcock In-Reply-To: References: Message-ID: > I had been going under the assumption that I could interpret the presentation times in terms of the server's wallclock. I just realized that, in fact, presentation time appears to have been converted to the client's local time No. The received frames' presentation times (once they've been RTCP-synchronized) are *server-generated* values - i.e., based on the server's clock. If the server's clock is running 'fast' (or 'slow'), compared to the client's clock, then the presentation times will also run 'fast' (or 'slow') accordingly. Also, the protocol does not tell you the *absolute* values of the (server-generated) presentation times. A server's presentation times don't have to be synchronized using the Network Time Protocol, or anything else; they can start at any value. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Wed Apr 3 01:28:49 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Wed, 3 Apr 2013 09:28:49 +0100 Subject: [Live-devel] OutPacketBuffer::maxSize should be larger by default? In-Reply-To: <59898EC5-16B4-463C-B644-2F578FAD5794@live555.com> References: <59898EC5-16B4-463C-B644-2F578FAD5794@live555.com> Message-ID: This unfortunately seems more common than not. I have several Axis, Vivotek, Sony, ACTi, D-Link, Lilin and Chinese no brand cameras and they are all generating ridiculously large frames :( Maybe the value can be an argument option without having to recompile? - Or maybe it can be larger but still print warnings unless silenced with --quiet? Also, not sure if you saw my other thread about ProxyServer causing an RTSP client to freeze? On 3 April 2013 02:01, Ross Finlayson wrote: > Is there any reason this buffer is so small by default? > > > This value is not 'small'. On the contrary - it's your cameras that are > generating ridiculously 'large' frames :-) > > "OutPacketBuffer::maxSize" defines the largest possible 'frame' that a > server (or a proxy server) can send. It's important to understand that > each outgoing frame - if it is larger than the RTP/UDP packet size (about > 1500 bytes on most networks) - will be broken up into multiple outgoing RTP > packets, and the receiver must receive *all* of these packets in order to > be able to reconstruct the frame. In other words, if even one of these > packets is lost, then the receiver will lose the *entire* frame. > > The default 60000 byte size corresponds to a sequence of about *20* > RTP/UDP packets (assuming a standard ~1500 byte MTU). Internet streaming > servers should not be generating frames that are this large. But if they > do, it's useful to have our code print out an error message, telling them > that they're doing something that they shouldn't. (Ditto if you're trying > to proxy frames this large; this will not work if the network in front of > the proxy server has any significant packet loss. But if these networks > happen to have no packet loss, then you can easily update your code to > increase "OutPacketBuffer::maxSize".) > > I might end up increasing the default "OutPacketBuffer::maxSize" to 65000 > kBytes (because such a frame would be large enough to fit inside a single > 65536-byte UDP packet - the largest possible). But I'm not going to make > the default size larger than this, because developers need to be aware of > the consequences of having their servers (try to) transmit ridiculously > large frames. > > > 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 shrishty.deorari at vvdntech.com Wed Apr 3 04:48:18 2013 From: shrishty.deorari at vvdntech.com (Shrishty Deorari) Date: Wed, 3 Apr 2013 17:18:18 +0530 Subject: [Live-devel] Streaming .h264 and .aac together Message-ID: Hi, I have query regarding .aac audio file. In testprogs/ directory we have executable file for every type of format(like .mpeg4, .h264, .mpeg1or2 etc) but not for .aac(or we can say ADTS format) , streaming this format is only given through testOndemandRTSPserver .why? is it not possible to stream this file like other/ it can ony be done using testOndemandRTSPserver. I want to stream .H264 (video) and .aac (audio) together,taking them from two different file and then combining them before streaming. right now i have linked them to one servermedia session(sms) and tried to read from two files using Bytestreamfilesource. is this can be done. what should be the approach ,which i should take? thanks and regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 3 06:40:44 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Apr 2013 06:40:44 -0700 Subject: [Live-devel] Streaming .h264 and .aac together In-Reply-To: References: Message-ID: <92108EC1-92C8-4772-83AB-3FF65B17930B@live555.com> > I have query regarding .aac audio file. In testprogs/ directory we have executable file for every type of format(like .mpeg4, .h264, .mpeg1or2 etc) but not for .aac(or we can say ADTS format) , streaming this format is only given through testOndemandRTSPserver .why? Simply because I never got around to writing a "testAACAudioStreamer" (multicast streaming) application. But such an application would be easy to write. (Look at "liveMedia/ADTSAudioFileServerMediaSubsession.cpp" to see how (for unicast streaming) we create a source object (from an ADTS-format file) and sink objects for streaming.) > I want to stream .H264 (video) and .aac (audio) together,taking them from two different file and then combining them before streaming. right now i have linked them to one servermedia session(sms) > and tried to read from two files using Bytestreamfilesource. > is this can be done. Yes, this will work. However, you may have trouble getting audio and video (because they come from separate files) in synch. (I.e., you may have trouble ensuring that each source object's "presentationTime" values are properly synchronized. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Serge.Grondin at miranda.com Wed Apr 3 10:24:51 2013 From: Serge.Grondin at miranda.com (Serge.Grondin at miranda.com) Date: Wed, 3 Apr 2013 13:24:51 -0400 Subject: [Live-devel] H264VideoRTPSink type cast issue Message-ID: Hi there, I recently updated to the latest version of the library (March 23rd 2013 version) but I came across a new issue with H264VideoRTPSink. In the function doSpecialFrameHandling there is "specific" type cast of the frame source to H264VideoStreamFramer but since my source is not this class, my code now crashes. The easy work-around for me is to derive a new sink class from H264VideoRTPSink and overwrite the problematic function, but, although it is declared virtual, the function is private in the header file (which is pretty much useless to use the keyword virtual in this case). Can you make this function protected in you next release? This way I won't have to patch the library and this will also bring a solution for other people who uses the H264VideoRTPSink with a different input source than H264VideoStreamFramer. Thanks! Serge DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 3 11:49:53 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Apr 2013 11:49:53 -0700 Subject: [Live-devel] H264VideoRTPSink type cast issue In-Reply-To: References: Message-ID: > I recently updated to the latest version of the library (March 23rd 2013 version) but I came across a new issue with H264VideoRTPSink. In the function doSpecialFrameHandling there is "specific" type cast of the frame source to H264VideoStreamFramer > That's correct. That code has been there for many years, so the fact that it is an issue for you only with this new release of the code suggests that you probably had made improper modifications to whatever version of the code you were using before. > but since my source is not this class, my code now crashes. > That should not be happening, because if if you try to call "getPlaying()" on a "H264VideoRTPSink" with an object that is *not* a "H264VideoStreamFramer", you should never get to that code, because the previous call to "sourceIsCompatibleWithUs()" on line 70 of "MediaSink.cpp" should have returned False. (This is because "H264VideoRTPSink" reimplements the "sourceIsCompatibleWithUs()" virtual function to return True only if the source object is a "H264VideoStreamFramer".) So this suggests that you are *still* making changes to the supplied source code. Please stop doing this, if you want to get support on this mailing list! See: http://www.live555.com/liveMedia/faq.html#modifying-and-extending The bottom line is that the object that feeds into a "H264VideoRTPSink" *must* be a "H264VideoStreamFramer", or a subclass of this. The solution is simple: Create a "H264VideoStreamDiscreteFramer" (note, *not* a "H264VideoStreamFramer") object in front of your source object (i.e., in front of the object that delivers discrete H.264 NAL units - presumably from an encoder). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Serge.Grondin at miranda.com Wed Apr 3 12:23:50 2013 From: Serge.Grondin at miranda.com (Serge.Grondin at miranda.com) Date: Wed, 3 Apr 2013 15:23:50 -0400 Subject: [Live-devel] H264VideoRTPSink type cast issue In-Reply-To: References: Message-ID: Thanks for the quick answer. I have to add that I have not changed a single line of code in the source code, so I don't get it ? My previous code was working because I implemented the same Boolean function that returns the "isCurrentNALUnitEndsAU" so the type cast was working anyway. But now that this was changed to "Boolean& pictureEndMarker()", my work-around does not work anymore since it returns a reference to the actual Boolean in the class. I'm writing to the mailing list specially to avoid making change to the library! Anyway, I did not remember "sourceIsCompatibleWithUs()" function, I wrote that code 2 years ago and I just realized that I wrongly implemented the virtual function and was returning True, that explains everything. I was just lucky that my previous code was working. Thanks again. Serge From: Ross Finlayson To: LIVE555 Streaming Media - development & use , Date: 2013-04-03 14:54 Subject: Re: [Live-devel] H264VideoRTPSink type cast issue Sent by: live-devel-bounces at ns.live555.com I recently updated to the latest version of the library (March 23rd 2013 version) but I came across a new issue with H264VideoRTPSink. In the function doSpecialFrameHandling there is "specific" type cast of the frame source to H264VideoStreamFramer That's correct. That code has been there for many years, so the fact that it is an issue for you only with this new release of the code suggests that you probably had made improper modifications to whatever version of the code you were using before. but since my source is not this class, my code now crashes. That should not be happening, because if if you try to call "getPlaying()" on a "H264VideoRTPSink" with an object that is *not* a "H264VideoStreamFramer", you should never get to that code, because the previous call to "sourceIsCompatibleWithUs()" on line 70 of "MediaSink.cpp" should have returned False. (This is because "H264VideoRTPSink" reimplements the "sourceIsCompatibleWithUs()" virtual function to return True only if the source object is a "H264VideoStreamFramer".) So this suggests that you are *still* making changes to the supplied source code. Please stop doing this, if you want to get support on this mailing list! See: http://www.live555.com/liveMedia/faq.html#modifying-and-extending The bottom line is that the object that feeds into a "H264VideoRTPSink" *must* be a "H264VideoStreamFramer", or a subclass of this. The solution is simple: Create a "H264VideoStreamDiscreteFramer" (note, *not* a "H264VideoStreamFramer") object in front of your source object (i.e., in front of the object that delivers discrete H.264 NAL units - presumably from an encoder). 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 DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From ccaughie at openeye.net Wed Apr 3 13:50:34 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Wed, 3 Apr 2013 13:50:34 -0700 Subject: [Live-devel] OutPacketBuffer::maxSize should be larger bydefault? In-Reply-To: References: <59898EC5-16B4-463C-B644-2F578FAD5794@live555.com> Message-ID: <853C62832D606043A043BD770304786C041DF82E@EDD.pcopen.net> I concur; IP cameras are supporting higher and higher resolutions, and their maximum encoded frame size (particularly for I-frames) naturally increases in proportion. This can be mitigated by using H.264 slices but not many of them seem to do so. That?s not necessarily a reason to increase the default though (as long as it can be increased by individual applications); IP security cameras are only one of many applications of this code and presumably most of them involve streams that have been encoded to suit the needs of the average internet user, as opposed to the high-res, high-quality streams typically found in a surveillance scenario. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Roman Gaufman Sent: Wednesday, April 03, 2013 1:29 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] OutPacketBuffer::maxSize should be larger bydefault? This unfortunately seems more common than not. I have several Axis, Vivotek, Sony, ACTi, D-Link, Lilin and Chinese no brand cameras and they are all generating ridiculously large frames :( Maybe the value can be an argument option without having to recompile? - Or maybe it can be larger but still print warnings unless silenced with --quiet? Also, not sure if you saw my other thread about ProxyServer causing an RTSP client to freeze? On 3 April 2013 02:01, Ross Finlayson wrote: Is there any reason this buffer is so small by default? This value is not 'small'. On the contrary - it's your cameras that are generating ridiculously 'large' frames :-) "OutPacketBuffer::maxSize" defines the largest possible 'frame' that a server (or a proxy server) can send. It's important to understand that each outgoing frame - if it is larger than the RTP/UDP packet size (about 1500 bytes on most networks) - will be broken up into multiple outgoing RTP packets, and the receiver must receive *all* of these packets in order to be able to reconstruct the frame. In other words, if even one of these packets is lost, then the receiver will lose the *entire* frame. The default 60000 byte size corresponds to a sequence of about *20* RTP/UDP packets (assuming a standard ~1500 byte MTU). Internet streaming servers should not be generating frames that are this large. But if they do, it's useful to have our code print out an error message, telling them that they're doing something that they shouldn't. (Ditto if you're trying to proxy frames this large; this will not work if the network in front of the proxy server has any significant packet loss. But if these networks happen to have no packet loss, then you can easily update your code to increase "OutPacketBuffer::maxSize".) I might end up increasing the default "OutPacketBuffer::maxSize" to 65000 kBytes (because such a frame would be large enough to fit inside a single 65536-byte UDP packet - the largest possible). But I'm not going to make the default size larger than this, because developers need to be aware of the consequences of having their servers (try to) transmit ridiculously large frames. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 3 13:52:03 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Apr 2013 13:52:03 -0700 Subject: [Live-devel] H264VideoRTPSink type cast issue In-Reply-To: References: Message-ID: <28277A83-8019-4842-898F-C99EBD38EF38@live555.com> As long as the object that you feed to your "H264VideoRTPSink" is a "H264VideoStreamFramer" - or a subclass thereof - everything should work OK. But rather than writing your own subclass of "H264VideoStreamFramer", why not just use the "H264VideoStreamDiscreteFramer" subclass that we have already provided to you? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Wed Apr 3 04:08:47 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Wed, 3 Apr 2013 11:08:47 +0000 Subject: [Live-devel] OutPacketBuffer::maxSize should be larger by default? In-Reply-To: References: <59898EC5-16B4-463C-B644-2F578FAD5794@live555.com>, Message-ID: <615FD77639372542BF647F5EBAA2DBC2252E120A@IL-BOL-EXCH01.smartwire.com> I deal with security cameras and over time, the resolutions have been getting higher. They love to crank up the quality and resolution to give users that initial: "Wow this camera has a nice picture" But our customers are bandwidth sensitive and the first thing we have to do is change the settings on the camera. For us the number of network packets is not the issue, it is the key frames. This is each image in MJPEG. (MJPEG is never compressed as much as a key frame on H264 but they are close.) I see abut 29K for a 720 x 480 key frame I have seen 59K for the same on Samsung/GVI The few cameras giving 1280x1024 always go over. To my understanding Live 555 can handle Periodic Intra Refresh, we just need to get the camera manufactures to embrace it. ________________________________ From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] on behalf of Roman Gaufman [hackeron at gmail.com] Sent: Wednesday, April 03, 2013 3:28 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] OutPacketBuffer::maxSize should be larger by default? This unfortunately seems more common than not. I have several Axis, Vivotek, Sony, ACTi, D-Link, Lilin and Chinese no brand cameras and they are all generating ridiculously large frames :( Maybe the value can be an argument option without having to recompile? - Or maybe it can be larger but still print warnings unless silenced with --quiet? Also, not sure if you saw my other thread about ProxyServer causing an RTSP client to freeze? This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. On 3 April 2013 02:01, Ross Finlayson > wrote: Is there any reason this buffer is so small by default? This value is not 'small'. On the contrary - it's your cameras that are generating ridiculously 'large' frames :-) "OutPacketBuffer::maxSize" defines the largest possible 'frame' that a server (or a proxy server) can send. It's important to understand that each outgoing frame - if it is larger than the RTP/UDP packet size (about 1500 bytes on most networks) - will be broken up into multiple outgoing RTP packets, and the receiver must receive *all* of these packets in order to be able to reconstruct the frame. In other words, if even one of these packets is lost, then the receiver will lose the *entire* frame. The default 60000 byte size corresponds to a sequence of about *20* RTP/UDP packets (assuming a standard ~1500 byte MTU). Internet streaming servers should not be generating frames that are this large. But if they do, it's useful to have our code print out an error message, telling them that they're doing something that they shouldn't. (Ditto if you're trying to proxy frames this large; this will not work if the network in front of the proxy server has any significant packet loss. But if these networks happen to have no packet loss, then you can easily update your code to increase "OutPacketBuffer::maxSize".) I might end up increasing the default "OutPacketBuffer::maxSize" to 65000 kBytes (because such a frame would be large enough to fit inside a single 65536-byte UDP packet - the largest possible). But I'm not going to make the default size larger than this, because developers need to be aware of the consequences of having their servers (try to) transmit ridiculously large frames. 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 Jesse.Hemingway at nerdery.com Wed Apr 3 05:12:31 2013 From: Jesse.Hemingway at nerdery.com (Jesse Hemingway) Date: Wed, 3 Apr 2013 07:12:31 -0500 Subject: [Live-devel] Getting server wallcock In-Reply-To: References: Message-ID: OK, then I think my mistake is to presume those timestamps are adjusted for the server's timezone settings. In fact, they must be UTC values, with no way to determine the timezone they originated from. In retrospect - duh, that's how you'd expect timestamps to work, and that's probably already documented somewhere. Let me know if I'm (still) misunderstanding. Thanks again! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 3 19:41:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Apr 2013 19:41:18 -0700 Subject: [Live-devel] Getting server wallcock In-Reply-To: References: Message-ID: > OK, then I think my mistake is to presume those timestamps are adjusted for the server's timezone settings. In fact, they must be UTC values, with no way to determine the timezone they originated from. In retrospect - duh, that's how you'd expect timestamps to work, and that's probably already documented somewhere. Let me know if I'm (still) misunderstanding. Yes, you are still misunderstanding, I think. Clients cannot infer anything from the value of a *single* (RTCP-synchronized) presentation time - because the presentation times come from the server, whose clock does not have to have been synchronized with NTP. (For example, the server might think that it's still the year 1995!) The server *might* have set its presentation times to (NTP-synchronized) UTC, or it might have set its presentation times to some other time zone, or it might have set its presentation times thinking that it's still the year 1995. But the client does not know this (nor does it need to, in almost all cases). Clients can, however, use the *difference* between two frames' presentation times to figure out when (relatively) each frame should be rendered. Also, if the stream contains both audio and video substreams, then the presentation times from the audio and video frames can be used to properly synchronize the audio and video. But anyway, because I'm tired of explaining the same thing over and over again, this will be my - and your - last posting on this topic. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Wed Apr 3 03:33:27 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Wed, 3 Apr 2013 11:33:27 +0100 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 Message-ID: With version 2012.12.24, live555ProxyServer can proxy Sony, Vivotek, Axis and other IP cameras, but after upgrading to 2013.01.25 or newer (tried with 2013.04.01 also), the proxy freezes with all of the above IP cameras. I have made a stream publicly available, to reproduce, run: ./proxyServer/live555ProxyServer rtsp://86.146.236.49/media/video1 ./testProgs/testRTSPClient rtsp://127.0.0.1/proxyStream The stream will freeze after a few minutes. When the stream is opened directly, it does not freeze: ./testProgs/testRTSPClient rtsp://86.146.236.49/media/video1 This seems to be related to the GET_PARAMETER code added after 2012.12.24 and this freeze happens immediately after seeing this in the live555ProxyServer output: Sending request: GET_PARAMETER rtsp://192.168.88.13/media/video1/ RTSP/1.0 CSeq: 23 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.23) Session: 1365014127 Content-Length: 2 After this is sent, the connection is lost and the RTSP client freezes: ProxyRTSPClient["rtsp://192.168.88.13/media/video1/"]: lost connection to server ('errno': 9). Resetting... ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::~ProxyServerMediaSubsession() Opening connection to 192.168.88.13, port 554... ...remote connection opened Sending request: DESCRIBE rtsp://192.168.88.13/media/video1 RTSP/1.0 CSeq: 24 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.03.23) Accept: application/sap Maybe the GET_PARAMETER command should not be sent during a live stream? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 3 19:56:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Apr 2013 19:56:43 -0700 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: References: Message-ID: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> > The stream will freeze after a few minutes. When the stream is opened directly, it does not freeze: > > ./testProgs/testRTSPClient rtsp://86.146.236.49/media/video1 Sorry, but I can't access this stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Wed Apr 3 23:36:45 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Thu, 4 Apr 2013 07:36:45 +0100 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> Message-ID: Hi, sorry, it's a dynamic IP and there was a power cut: rtsp://86.146.238.165/media/video1 On 4 April 2013 03:56, Ross Finlayson wrote: > The stream will freeze after a few minutes. When the stream is opened > directly, it does not freeze: > > ./testProgs/testRTSPClient rtsp://86.146.236.49/media/video1 > > > Sorry, but I can't access this stream. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 4 00:46:39 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Apr 2013 00:46:39 -0700 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> Message-ID: <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> > Hi, sorry, it's a dynamic IP and there was a power cut: > > rtsp://86.146.238.165/media/video1 OK, I've tested this now. You're correct that your camera server appears to crash (closing down the TCP connection) and reboot whenever it receives the proxy's "GET_PARAMETER" command. I.e., the camera appears to have a bug. (Note that camera response to the proxy's earlier "OPTIONS" command told us that it supported the "GET_PARAMETER" command; nonetheless, it appears to crash whenever we send it such a command.) Because the camera is buggy, you should check to see if it has a firmware upgrade available. If it doesn't, then please contact Sony, informing them of the bug. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Thu Apr 4 01:33:36 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Thu, 4 Apr 2013 09:33:36 +0100 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> Message-ID: Thanks for your fast reply. Unfortunately it appears to happen on all branded cameras I have to test: ACTi, Sony, Axis, D-Link, Vivotek and Lilin. I updated the firmware on this specific Sony camera to the latest last week. It appears to be a very typical response to kill the connection when receiving a GET_PARAMETER during a playing stream on all major IP cameras - which as I understand is against the standard :( Can some kind of workaround be added? - what are the benefits of sending a GET_PARAMETER during a playing stream? I am right now using the 2012.12.24 version of live555 because anything newer will not proxy most branded IP camera on the market :( On Thursday, 4 April 2013, Ross Finlayson wrote: > Hi, sorry, it's a dynamic IP and there was a power cut: > > rtsp://86.146.238.165/media/video1 > > > OK, I've tested this now. > > You're correct that your camera server appears to crash (closing down the > TCP connection) and reboot whenever it receives the proxy's "GET_PARAMETER" > command. I.e., the camera appears to have a bug. (Note that camera > response to the proxy's earlier "OPTIONS" command told us that it supported > the "GET_PARAMETER" command; nonetheless, it appears to crash whenever we > send it such a command.) > > Because the camera is buggy, you should check to see if it has a firmware > upgrade available. If it doesn't, then please contact Sony, informing them > of the bug. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 4 02:16:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Apr 2013 02:16:06 -0700 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> Message-ID: > Unfortunately it appears to happen on all branded cameras I have to test: ACTi, Sony, Axis, D-Link, Vivotek and Lilin. I find this very difficult to believe - especially considering that nobody else has reported this problem. Nonetheless, because you provided definitive evidence of at least one buggy server, I've now installed a new version (2013.04.04) of the code that should avoid crashing this server. The proxy code will now always sends "OPTIONS" - rather than "GET_PARAMETER" - as the 'liveness check' command, unless the server explicitly indicated (by a "Session:" header "timeout" parameter in the "SETUP" response) that it wants to receive periodic in-session "GET_PARAMETER" commands instead. (Some servers have another bug whereby they don't use RTCP "RR" packets - from the client (or proxy) - to indicate client (or proxy) liveness.) > It appears to be a very typical response to kill the connection when receiving a GET_PARAMETER during a playing stream on all major IP cameras - which as I understand is against the standard :( Yes, but I still find it strange that nobody else has reported this. (It would be nice to get independent confirmation of this from a professional user, and also have this bug reported to the camera manufacturer(s)!) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shrishty.deorari at vvdntech.com Thu Apr 4 05:44:06 2013 From: shrishty.deorari at vvdntech.com (Shrishty Deorari) Date: Thu, 4 Apr 2013 18:14:06 +0530 Subject: [Live-devel] (no subject) Message-ID: Hi, I tried to create the testAACAudiostreamer.cpp for streaming the .aac audio file in that i used MPEG4GenericRTPSink class for creating the audioSink (as i have read in previous live-devel answers that RTPSink" subclass that you would use for streaming AAC audio is a "MPEG4GenericRTPSink" and also as its been called in ADTSAudioFileServerMediaSubsession::createNewRTPsink( ) . Now the problem i am facing is when i did make , it is not creating object file for testAACAudiostreamer.cpp ,i have included this file inside Makefile of testprogs/ also. what i did exacty in my main file is : .......... RTPSink* audioSink; ......... ...... Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl); rtcpGroupsock.multicastSendOnly(); // we're a SSM source * audioSink = MPEG4GenericRTPSink::createNew(*env, &rtpGroupsock, 96);* so should i not use MPEG4GenericRTPSink directly here. the error which is coming during Make is: t*estAACAudioStreamer.cpp:42: error: no matching function for call to ?MPEG4GenericRTPSink::createNew(UsageEnvironment&, Groupsock*, int)?* *../liveMedia/include/MPEG4GenericRTPSink.hh:31: note: candidates are: static MPEG4GenericRTPSink* MPEG4GenericRTPSink::createNew(UsageEnvironment&, Groupsock*, u_int8_t, u_int32_t, const char*, const char*, const char*, unsigned int)* *make[1]: *** [testAACAudioStreamer.o] Error 1* please guide me what should i do? thanks and regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From aurelio.cano at inetsis.es Thu Apr 4 04:14:57 2013 From: aurelio.cano at inetsis.es (Aurelio Cano) Date: Thu, 04 Apr 2013 13:14:57 +0200 Subject: [Live-devel] Capturing RTP H.264 stream with testOnDemandRTSPServer Message-ID: <515D60B1.1030105@inetsis.es> Hi, The testOnDemandRTSPServer works great receiving RTP MPEG Transport Stream Packets (format code 33), but is there a strong resctriction for other payload types? What should I do for other types, i.e. RTP Payload Format for H.264 Video (format code: 96)? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 4 08:22:24 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Apr 2013 08:22:24 -0700 Subject: [Live-devel] (no subject) In-Reply-To: References: Message-ID: On Apr 4, 2013, at 5:44 AM, Shrishty Deorari wrote: > what i did exacty in my main file is : .......... > RTPSink* audioSink; > ......... > ...... > Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl); > rtcpGroupsock.multicastSendOnly(); // we're a SSM source > > audioSink = MPEG4GenericRTPSink::createNew(*env, &rtpGroupsock, 96); > so should i not use MPEG4GenericRTPSink directly here. > the error which is coming during Make is: > > > > testAACAudioStreamer.cpp:42: error: no matching function for call to ?MPEG4GenericRTPSink::createNew(UsageEnvironment&, Groupsock*, int)? > ../liveMedia/include/MPEG4GenericRTPSink.hh:31: note: candidates are: static MPEG4GenericRTPSink* MPEG4GenericRTPSink::createNew(UsageEnvironment&, Groupsock*, u_int8_t, u_int32_t, const char*, const char*, const char*, unsigned int) > make[1]: *** [testAACAudioStreamer.o] Error 1 Is it not obvious from this error what the problem is? Obviously, you are not calling "MPEG4GenericRTPSink::createNew()" correctly. Look at "liveMedia/include/MPEG4GenericRTPSink.hh", and you will see why your call to "MPEG4GenericRTPSink::createNew()" is incorrect. You need to pass more parameters to "MPEG4GenericRTPSink::createNew()". Specifically (using the example code in "ADTSAudioFileServerMediaSubsession.cpp": MPEG4GenericRTPSink::createNew(envir(), rtpGroupsock, 96, adtsSource->samplingFrequency(), "audio", "AAC-hbr", adtsSource->configStr(), adtsSource->numChannels()); where "adtsSource" is a "ADTSAudioFileSource" that you have previously created by: ADTSAudioFileSource* adtsSource = ADTSAudioFileSource::createNew(envir(), inputFileName); Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 4 08:33:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Apr 2013 08:33:07 -0700 Subject: [Live-devel] Capturing RTP H.264 stream with testOnDemandRTSPServer In-Reply-To: <515D60B1.1030105@inetsis.es> References: <515D60B1.1030105@inetsis.es> Message-ID: <97361B39-4480-4285-BB77-315E55A02320@live555.com> > What should I do for other types, i.e. RTP Payload Format for H.264 Video (format code: 96)? I can't answer this unless you tell me specifically what kind of stream this is - i.e., how it is delivered. Is this stream served with a RTSP server of its own? I.e., does it have its own "rtsp://" URL. If so, you can either access it directly - using this URL - without using an intermediate server. Or, alternatively, use the "LIVE555 Proxy Server": http://www.live555.com/proxyServer/ Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 842598566 at qq.com Thu Apr 4 03:38:02 2013 From: 842598566 at qq.com (=?ISO-8859-1?B?YWxpYXM=?=) Date: Thu, 4 Apr 2013 18:38:02 +0800 Subject: [Live-devel] how do i modify live555ProxyServer to make it work like live555MediaServer Message-ID: how do i modify live555ProxyServer so let it work like live555MediaServer, when i want to get a stream source that live555ProxyServer hadn't create a link of this source when it started up, live555ProxyServer can link this new source and brocasts it so i can get it by another program like "openRtsp". -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 4 18:45:34 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Apr 2013 18:45:34 -0700 Subject: [Live-devel] how do i modify live555ProxyServer to make it work like live555MediaServer In-Reply-To: References: Message-ID: Please DO NOT ask the same question on the mailing list multiple times. (This is explained in the FAQ!) I already answered your question two days ago. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From louxkr at gmail.com Thu Apr 4 09:36:40 2013 From: louxkr at gmail.com (Kerry Loux) Date: Thu, 4 Apr 2013 12:36:40 -0400 Subject: [Live-devel] Not receiving frames from H264 stream In-Reply-To: References: Message-ID: I should have finished working through the advice in the FAQ - openRTSP successfully streamed from my cameras with the -t option, and setting the fourth argument of setupSubsession() to true fixed my problems. I also found that I did not need to specify the video resolution in order to get a proper stream, so I would still be interested in a response to my second question. I apologize for not trying the advice in the FAQ before posting :-) Thanks, Kerry On Thu, Apr 4, 2013 at 10:25 AM, Kerry Loux wrote: > Hello, > > I'm just getting started with Live555, and have a couple questions that I > haven't been able to resolve by searching. > > I have successfully compiled a test application that can connect and > stream from this url: > rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov > > I'm using an H264VideoFileSink object and it works just fine. > > If I instead use the url for a local IP camera, I find that > H264VideoFileSink::afterGettingFrame() is not called (and thus my file has > zero size). > > I can stream this url using VLC without any problems (VLC describes the > stream as H264 - MPEG AVC (part 10) (h264)). The SDP string for my camera > is below: > > v=0 > o=- 2251938208 2251938208 IN IP4 0.0.0.0 > s=RTSP Session of ZheJiang Dahua Technology CO.,LTD. > t=0 0 > a=control:* > a=range:npt=now- > a=packetization-supported:DH > m=video 0 RTP/AVP 96 > a=control:trackID=0 > a=framerate:30.000000 > a=rtpmap:96 H264/90000 > a=fmtp:96 > packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=Z00AH9oBQBbpUgAAAwACAADAHjAgAB8/4AAIyf973wvCIRq,aM48gA== > m=audio 0 RTP/AVP 8 > a=control:trackID=1 > a=rtpmap:8 PCMA/8000 > > By looking at the SDP string for the working stream, I found that the SDP > from my camera lacks these lines under m=video...: (I modified these to > match the size of the image provided by my camera) > a=cliprect:0,0,1280,720 > a=framesize:96 720-1280 > > I read in the FAQ for openRTSP that the video dimensions are important, so > I tried inserting these into the SDP prior to calling > MediaSession::createNew, and of course it didn't work (this causes my > application to crash - I knew it was a shot in the dark). > > So now my questions: > 1. Any thoughts on why afterGettingFrame() isn't being called? > 2. Do I need to worry about the height and width parameters? I'm guessing > they're included in maybe the sprop-parameter string, and this doesn't > apply to H264 streams (or at least this stream) since VLC doesn't need to > ask me for the resolution. > > Thanks, > > Kerry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tboonefisher at clear.net Thu Apr 4 12:26:55 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Thu, 4 Apr 2013 14:26:55 -0500 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream Message-ID: <83B9617CAE5B45F9A1F79D52ECF9F25D@tbxpnotebook> THANKS!!! For a VERY NICE library. I am experimenting with the testRTSPClient app to develop a DirectShow source filter to connect to a network camera outputting an H.264 video stream. The app successfully connects to the camera and shows the following continuous output: ... Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.117119 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 411 bytes. Presentation time: 1365102232.186298 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.226244 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 458 bytes. Presentation time: 1365102232.375975 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.359869 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.465869 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.585744 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 950 bytes. Presentation time: 1365102232.666086 ... Initially, I am only interested in the video portion of the stream. Using the library, what is the most efficient way to get access to the H.264 portion of the stream so that I can copy it downstream in the FillBuffer(..) method of my source filter? I have attempted to browse the code to learn how/where to do this, but it is not obvious to me;-(( I have (+-)intermediate level C++ skills at best, so any thoughts, suggestions, constructive criticism are(is) greatly appreciated. Thanks again for a VERY nice library. Tom Fisher EE -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Fri Apr 5 01:57:57 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Fri, 5 Apr 2013 09:57:57 +0100 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> Message-ID: On 4 April 2013 10:16, Ross Finlayson wrote: > I find this very difficult to believe - especially considering that nobody > else has reported this problem. > I'm not sure what to say but GET_PARAMETER is causing problems with almost all cameras I have here to test (excluding a Chinese no brand one ironically). I've made one more stream publicly available, this time from Axis - arguably the leaders in the market. The stream doesn't freeze as quickly as the Sony stream, but does freeze after a few minutes or so: rtsp://viewer:password at 86.162.35.136/axis-media/media.amp Instead of freezing after the first GET_PARAMETER like Sony, it seems to do this after a few GET_PARAMETER requests around the 2 and a half minute mark: Sending request: GET_PARAMETER rtsp://86.162.35.136/axis-media/media.amp/RTSP/1.0 CSeq: 11 Authorization: Digest username="viewer", realm="AXIS_00408CC61141", nonce="0003b3acY558862c87aa9f41d1bb2e0ce73a2ab572b750", uri="rtsp:// 86.162.35.136/axis-media/media.amp/", response="dba33206b01ca464ce5c693aeb55c6c1" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.01) Session: 0E2C46CE Content-Length: 2 Received 266 new bytes of response data. Received a complete GET_PARAMETER response: RTSP/1.0 401 Unauthorized CSeq: 11 Session: 0E2C46CE WWW-Authenticate: Digest realm="AXIS_00408CC61141", nonce="0003b442Y74661773895f565b0a7480ea3bff2193120c0", stale=TRUE WWW-Authenticate: Basic realm="AXIS_00408CC61141" Date: Fri, 05 Apr 2013 08:41:21 GMT ProxyServerMediaSubsession["H264"]::closeStreamSource() > > Nonetheless, because you provided definitive evidence of at least one > buggy server, I've now installed a new version (2013.04.04) of the code > that should avoid crashing this server. The proxy code will now always > sends "OPTIONS" - rather than "GET_PARAMETER" - as the 'liveness check' > command, unless the server explicitly indicated (by a "Session:" header > "timeout" parameter in the "SETUP" response) that it wants to receive > periodic in-session "GET_PARAMETER" commands instead. (Some servers have > another bug whereby they don't use RTCP "RR" packets - from the client (or > proxy) - to indicate client (or proxy) liveness.) > I've compiled the latest version and unfortunately I'm seeing the exact same output as above, after about 2 and a half minutes of streaming, I see this: Sending request: GET_PARAMETER rtsp://86.162.35.136/axis-media/media.amp/RTSP/1.0 CSeq: 11 Authorization: Digest username="viewer", realm="AXIS_00408CC61141", nonce="0003b564Y2228267e47cfeaebe489a7adc01614e45c593", uri="rtsp:// 86.162.35.136/axis-media/media.amp/", response="68581b599686f52057b105915c628adf" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.05) Session: F1965CF1 Content-Length: 2 Received 266 new bytes of response data. Received a complete GET_PARAMETER response: RTSP/1.0 401 Unauthorized CSeq: 11 Session: F1965CF1 WWW-Authenticate: Digest realm="AXIS_00408CC61141", nonce="0003b5faY417690407232ac53139bf9e460a425d4722ba", stale=TRUE WWW-Authenticate: Basic realm="AXIS_00408CC61141" Date: Fri, 05 Apr 2013 08:48:42 GMT Yes, but I still find it strange that nobody else has reported this. (It > would be nice to get independent confirmation of this from a professional > user, and also have this bug reported to the camera manufacturer(s)!) > I noticed this problem back in January, but just used the 2012.12.24 version assuming some kind of PEBKAC since I have a couple of patches I used (like allowing to specify a port from the command line), but then reproduced it with vanilla. I am also very surprised nobody reported this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 5 02:05:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Apr 2013 02:05:15 -0700 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> Message-ID: > I've compiled the latest version and unfortunately I'm seeing the exact same output as above, after about 2 and a half minutes of streaming, I see this: > > Sending request: GET_PARAMETER rtsp://86.162.35.136/axis-media/media.amp/ RTSP/1.0 You must not have upgraded properly. With the latest version of the code the proxy server will never send "GET_PARAMETER" anymore (for that server). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 5 02:32:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Apr 2013 02:32:15 -0700 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> Message-ID: <8257FC57-4DA2-4D46-B7FA-60649657158A@live555.com> > I've compiled the latest version and unfortunately I'm seeing the exact same output as above, after about 2 and a half minutes of streaming, I see this: > > Sending request: GET_PARAMETER rtsp://86.162.35.136/axis-media/media.amp/ RTSP/1.0 Oops, sorry - my mistake. My earlier 'fix' wasn't working properly, in all circumstances. I'll install a new version tomorrow that should fix this for real. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shrishty.deorari at vvdntech.com Fri Apr 5 03:33:57 2013 From: shrishty.deorari at vvdntech.com (Shrishty Deorari) Date: Fri, 5 Apr 2013 16:03:57 +0530 Subject: [Live-devel] live-devel Digest, Vol 114, Issue 8 In-Reply-To: References: Message-ID: Finally i was able to create /testAACAudioStreamer. thanks to you.. On Fri, Apr 5, 2013 at 2:32 PM, 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: Capturing RTP H.264 stream with testOnDemandRTSPServer > (Ross Finlayson) > 2. how do i modify live555ProxyServer to make it work like > live555MediaServer (=?ISO-8859-1?B?YWxpYXM=?=) > 3. Re: how do i modify live555ProxyServer to make it work like > live555MediaServer (Ross Finlayson) > 4. Re: Not receiving frames from H264 stream (Kerry Loux) > 5. testRTSPClient / H.264 Network Camera Stream > (tboonefisher at clear.net) > 6. Re: live555ProxyServer freezes after upgrading from > 2012.12.24 (Roman Gaufman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 4 Apr 2013 08:33:07 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] Capturing RTP H.264 stream with > testOnDemandRTSPServer > Message-ID: <97361B39-4480-4285-BB77-315E55A02320 at live555.com> > Content-Type: text/plain; charset="iso-8859-1" > > > What should I do for other types, i.e. RTP Payload Format for H.264 > Video (format code: 96)? > > I can't answer this unless you tell me specifically what kind of stream > this is - i.e., how it is delivered. > > Is this stream served with a RTSP server of its own? I.e., does it have > its own "rtsp://" URL. If so, you can either access it directly - using > this URL - without using an intermediate server. Or, alternatively, use > the "LIVE555 Proxy Server": http://www.live555.com/proxyServer/ > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.live555.com/pipermail/live-devel/attachments/20130404/dc976999/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 4 Apr 2013 18:38:02 +0800 > From: "=?ISO-8859-1?B?YWxpYXM=?=" <842598566 at qq.com> > To: "=?ISO-8859-1?B?bGl2ZS1kZXZlbA==?=" > Subject: [Live-devel] how do i modify live555ProxyServer to make it > work like live555MediaServer > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > how do i modify live555ProxyServer so let it work like > live555MediaServer, when i want to get a stream source that > live555ProxyServer hadn't create a link of this source when it started up, > live555ProxyServer can link this new source and brocasts it so i can get it > by another program like "openRtsp". > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.live555.com/pipermail/live-devel/attachments/20130404/ec48adce/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 4 Apr 2013 18:45:34 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] how do i modify live555ProxyServer to make > it work like live555MediaServer > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > Please DO NOT ask the same question on the mailing list multiple times. > (This is explained in the FAQ!) I already answered your question two days > ago. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.live555.com/pipermail/live-devel/attachments/20130404/5e037f8f/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Thu, 4 Apr 2013 12:36:40 -0400 > From: Kerry Loux > To: live-devel at ns.live555.com > Subject: Re: [Live-devel] Not receiving frames from H264 stream > Message-ID: > SJpdQfoGjqr8LcN67T3e7D62eDi0MTEybGnmQ+ko-rQ at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > I should have finished working through the advice in the FAQ - openRTSP > successfully streamed from my cameras with the -t option, and setting the > fourth argument of setupSubsession() to true fixed my problems. > > I also found that I did not need to specify the video resolution in order > to get a proper stream, so I would still be interested in a response to my > second question. > > I apologize for not trying the advice in the FAQ before posting :-) > > Thanks, > > Kerry > > > On Thu, Apr 4, 2013 at 10:25 AM, Kerry Loux wrote: > > > Hello, > > > > I'm just getting started with Live555, and have a couple questions that I > > haven't been able to resolve by searching. > > > > I have successfully compiled a test application that can connect and > > stream from this url: > > rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov > > > > I'm using an H264VideoFileSink object and it works just fine. > > > > If I instead use the url for a local IP camera, I find that > > H264VideoFileSink::afterGettingFrame() is not called (and thus my file > has > > zero size). > > > > I can stream this url using VLC without any problems (VLC describes the > > stream as H264 - MPEG AVC (part 10) (h264)). The SDP string for my > camera > > is below: > > > > v=0 > > o=- 2251938208 2251938208 IN IP4 0.0.0.0 > > s=RTSP Session of ZheJiang Dahua Technology CO.,LTD. > > t=0 0 > > a=control:* > > a=range:npt=now- > > a=packetization-supported:DH > > m=video 0 RTP/AVP 96 > > a=control:trackID=0 > > a=framerate:30.000000 > > a=rtpmap:96 H264/90000 > > a=fmtp:96 > > > packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=Z00AH9oBQBbpUgAAAwACAADAHjAgAB8/4AAIyf973wvCIRq,aM48gA== > > m=audio 0 RTP/AVP 8 > > a=control:trackID=1 > > a=rtpmap:8 PCMA/8000 > > > > By looking at the SDP string for the working stream, I found that the SDP > > from my camera lacks these lines under m=video...: (I modified these to > > match the size of the image provided by my camera) > > a=cliprect:0,0,1280,720 > > a=framesize:96 720-1280 > > > > I read in the FAQ for openRTSP that the video dimensions are important, > so > > I tried inserting these into the SDP prior to calling > > MediaSession::createNew, and of course it didn't work (this causes my > > application to crash - I knew it was a shot in the dark). > > > > So now my questions: > > 1. Any thoughts on why afterGettingFrame() isn't being called? > > 2. Do I need to worry about the height and width parameters? I'm > guessing > > they're included in maybe the sprop-parameter string, and this doesn't > > apply to H264 streams (or at least this stream) since VLC doesn't need to > > ask me for the resolution. > > > > Thanks, > > > > Kerry > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.live555.com/pipermail/live-devel/attachments/20130404/2c6220e8/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Thu, 4 Apr 2013 14:26:55 -0500 > From: > To: > Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream > Message-ID: <83B9617CAE5B45F9A1F79D52ECF9F25D at tbxpnotebook> > Content-Type: text/plain; charset="iso-8859-1" > > THANKS!!! For a VERY NICE library. > > I am experimenting with the testRTSPClient app to develop a DirectShow > source filter to connect to a network camera outputting an H.264 > video stream. The app successfully connects to the camera and shows the > following continuous output: > ... > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received > 960 bytes. Presentation time: 1365102232.117119 > Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received > 411 bytes. Presentation time: 1365102232.186298 > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received > 960 bytes. Presentation time: 1365102232.226244 > Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received > 458 bytes. Presentation time: 1365102232.375975 > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received > 960 bytes. Presentation time: 1365102232.359869 > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received > 960 bytes. Presentation time: 1365102232.465869 > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received > 960 bytes. Presentation time: 1365102232.585744 > Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received > 950 bytes. Presentation time: 1365102232.666086 > ... > > Initially, I am only interested in the video portion of the stream. > Using the library, what is the most efficient way to get access to the > H.264 portion of the stream so that I can copy it downstream > in the FillBuffer(..) method of my source filter? > > I have attempted to browse the code to learn how/where to do this, but it > is not obvious to me;-(( > > I have (+-)intermediate level C++ skills at best, so any thoughts, > suggestions, constructive criticism > are(is) greatly appreciated. > > Thanks again for a VERY nice library. > > Tom Fisher EE > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.live555.com/pipermail/live-devel/attachments/20130404/fdf37292/attachment-0001.html > > > > ------------------------------ > > Message: 6 > Date: Fri, 5 Apr 2013 09:57:57 +0100 > From: Roman Gaufman > To: "LIVE555 Streaming Media - development & use" > > Subject: Re: [Live-devel] live555ProxyServer freezes after upgrading > from 2012.12.24 > Message-ID: > < > CAAs9BZP5cbG8uSztKgbgKJ3Q5_VUhTdmQ9O-FbXYyzMBFo8Jnw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On 4 April 2013 10:16, Ross Finlayson wrote: > > > I find this very difficult to believe - especially considering that > nobody > > else has reported this problem. > > > > I'm not sure what to say but GET_PARAMETER is causing problems with almost > all cameras I have here to test (excluding a Chinese no brand one > ironically). I've made one more stream publicly available, this time from > Axis - arguably the leaders in the market. > > The stream doesn't freeze as quickly as the Sony stream, but does freeze > after a few minutes or so: > > rtsp://viewer:password at 86.162.35.136/axis-media/media.amp > > Instead of freezing after the first GET_PARAMETER like Sony, it seems to do > this after a few GET_PARAMETER requests around the 2 and a half minute > mark: > > Sending request: GET_PARAMETER > rtsp://86.162.35.136/axis-media/media.amp/RTSP/1.0 > CSeq: 11 > Authorization: Digest username="viewer", realm="AXIS_00408CC61141", > nonce="0003b3acY558862c87aa9f41d1bb2e0ce73a2ab572b750", uri="rtsp:// > 86.162.35.136/axis-media/media.amp/", > response="dba33206b01ca464ce5c693aeb55c6c1" > User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.01) > Session: 0E2C46CE > Content-Length: 2 > > > > Received 266 new bytes of response data. > Received a complete GET_PARAMETER response: > RTSP/1.0 401 Unauthorized > CSeq: 11 > Session: 0E2C46CE > WWW-Authenticate: Digest realm="AXIS_00408CC61141", > nonce="0003b442Y74661773895f565b0a7480ea3bff2193120c0", stale=TRUE > WWW-Authenticate: Basic realm="AXIS_00408CC61141" > Date: Fri, 05 Apr 2013 08:41:21 GMT > > > ProxyServerMediaSubsession["H264"]::closeStreamSource() > > > > > > Nonetheless, because you provided definitive evidence of at least one > > buggy server, I've now installed a new version (2013.04.04) of the code > > that should avoid crashing this server. The proxy code will now always > > sends "OPTIONS" - rather than "GET_PARAMETER" - as the 'liveness check' > > command, unless the server explicitly indicated (by a "Session:" header > > "timeout" parameter in the "SETUP" response) that it wants to receive > > periodic in-session "GET_PARAMETER" commands instead. (Some servers have > > another bug whereby they don't use RTCP "RR" packets - from the client > (or > > proxy) - to indicate client (or proxy) liveness.) > > > > I've compiled the latest version and unfortunately I'm seeing the exact > same output as above, after about 2 and a half minutes of streaming, I see > this: > > Sending request: GET_PARAMETER > rtsp://86.162.35.136/axis-media/media.amp/RTSP/1.0 > CSeq: 11 > Authorization: Digest username="viewer", realm="AXIS_00408CC61141", > nonce="0003b564Y2228267e47cfeaebe489a7adc01614e45c593", uri="rtsp:// > 86.162.35.136/axis-media/media.amp/", > response="68581b599686f52057b105915c628adf" > User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.05) > Session: F1965CF1 > Content-Length: 2 > > > > Received 266 new bytes of response data. > Received a complete GET_PARAMETER response: > RTSP/1.0 401 Unauthorized > CSeq: 11 > Session: F1965CF1 > WWW-Authenticate: Digest realm="AXIS_00408CC61141", > nonce="0003b5faY417690407232ac53139bf9e460a425d4722ba", stale=TRUE > WWW-Authenticate: Basic realm="AXIS_00408CC61141" > Date: Fri, 05 Apr 2013 08:48:42 GMT > > Yes, but I still find it strange that nobody else has reported this. (It > > would be nice to get independent confirmation of this from a professional > > user, and also have this bug reported to the camera manufacturer(s)!) > > > > > I noticed this problem back in January, but just used the 2012.12.24 > version assuming some kind of PEBKAC since I have a couple of patches I > used (like allowing to specify a port from the command line), but then > reproduced it with vanilla. I am also very surprised nobody reported this. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.live555.com/pipermail/live-devel/attachments/20130405/f0be48e6/attachment.html > > > > ------------------------------ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > End of live-devel Digest, Vol 114, Issue 8 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Fri Apr 5 06:12:39 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Fri, 5 Apr 2013 15:12:39 +0200 Subject: [Live-devel] Unitialized memory in RTPReceptionStats Message-ID: <27885_1365167561_515ECDC9_27885_6183_2_1BE8971B6CFF3A4F97AF4011882AA25501561039B8DB@THSONEA01CMS01P.one.grp> Hi Ross, I know you don't like valgrind tool, but it reports use of uninitialized memory : Conditional jump or move depends on uninitialised value(s) (see: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.uninitvals) at 0x1036E23: RTCPInstance::enqueueReportBlock(RTPReceptionStats*) (RTCP.cpp:811) by 0x1036D17: RTCPInstance::enqueueCommonReportSuffix() (RTCP.cpp:782) by 0x1036BCC: RTCPInstance::addRR() (RTCP.cpp:744) by 0x1036A3A: RTCPInstance::addReport() (RTCP.cpp:710) by 0x1036767: RTCPInstance::sendReport() (RTCP.cpp:627) by 0x1037594: SendRTCPReport (RTCP.cpp:965) by 0x10379C2: OnExpire (rtcp_from_spec.c:202) by 0x103740E: RTCPInstance::onExpire1() (RTCP.cpp:926) by 0x10369B7: RTCPInstance::onExpire(RTCPInstance*) (RTCP.cpp:693) by 0x10895D0: AlarmHandler::handleTimeout() (BasicTaskScheduler0.cpp:34) by 0x1088419: DelayQueue::handleAlarm() (DelayQueue.cpp:184) by 0x108714D: BasicTaskScheduler::SingleStep(unsigned int) (BasicTaskScheduler.cpp:205) by 0x10854E3: BasicTaskScheduler0::doEventLoop(char*) (BasicTaskScheduler0.cpp:81) Uninitialised value was created by a heap allocation at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) by 0x1026FCF: RTPReceptionStatsDB::noteIncomingSR(unsigned int, unsigned int, unsigned int, unsigned int) (RTPSource.cpp:134) by 0x103619B: RTCPInstance::incomingReportHandler1() (RTCP.cpp:445) by 0x1035DDE: RTCPInstance::incomingReportHandler(RTCPInstance*, int) (RTCP.cpp:319) by 0x1086D2B: BasicTaskScheduler::SingleStep(unsigned int) (BasicTaskScheduler.cpp:146) by 0x10854E3: BasicTaskScheduler0::doEventLoop(char*) (BasicTaskScheduler0.cpp:81) A way to fix this is to initialize void RTPReceptionStats::init(u_int32_t SSRC) { fSSRC = SSRC; fTotNumPacketsReceived = 0; fTotBytesReceived_hi = fTotBytesReceived_lo = 0; + fBaseExtSeqNumReceived = 0; + fHighestExtSeqNumReceived = 0; fHaveSeenInitialSequenceNumber = False; Another way could be to check fHaveSeenInitialSequenceNumber in accessors, it's up to you. Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Reynel.Castelino at fike.com Fri Apr 5 06:27:02 2013 From: Reynel.Castelino at fike.com (Castelino, Reynel) Date: Fri, 5 Apr 2013 13:27:02 +0000 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: <8257FC57-4DA2-4D46-B7FA-60649657158A@live555.com> References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> <8257FC57-4DA2-4D46-B7FA-60649657158A@live555.com> Message-ID: <2C55BDC7C60FF64D894FC9E84A0B6F2E6FED9E64@BLSUSAEXCH1.fike.corp> Ross, Could this problem be related to another issue I've recently had with using proxy server with vlc as the back end server. The RTSP session timeout is hardcoded to 60 secs in VLC . The VLC RTSP server does support GET_PARAMETER and PAUSE as shown in OPTIONS. But when live555 proxy client sends it a GET_PARAMETER the response is a 451 client error and on sending PAUSE sends backs 405 error. VLC Server ends up sending a RTCP Bye message and disconnects the session. Thanks Reynel From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, April 05, 2013 5:32 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 I've compiled the latest version and unfortunately I'm seeing the exact same output as above, after about 2 and a half minutes of streaming, I see this: Sending request: GET_PARAMETER rtsp://86.162.35.136/axis-media/media.amp/ RTSP/1.0 Oops, sorry - my mistake. My earlier 'fix' wasn't working properly, in all circumstances. I'll install a new version tomorrow that should fix this for real. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 5 10:12:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Apr 2013 10:12:36 -0700 Subject: [Live-devel] Unitialized memory in RTPReceptionStats In-Reply-To: <27885_1365167561_515ECDC9_27885_6183_2_1BE8971B6CFF3A4F97AF4011882AA25501561039B8DB@THSONEA01CMS01P.one.grp> References: <27885_1365167561_515ECDC9_27885_6183_2_1BE8971B6CFF3A4F97AF4011882AA25501561039B8DB@THSONEA01CMS01P.one.grp> Message-ID: <4AFFA16A-5760-4708-88EB-F87CBB30324B@live555.com> > I know you don?t like valgrind tool I *do* like "valgrind". The problem with it, however, is that it frequently reports 'errors' that aren't really errors. Therefore, I generally don't pay attention when people send me "valgrind" reports, unless they can also note a specific problem in the code that is causing these reports to be generated. But fortunately you have done this. > A way to fix this is to initialize > void RTPReceptionStats::init(u_int32_t SSRC) { > fSSRC = SSRC; > fTotNumPacketsReceived = 0; > fTotBytesReceived_hi = fTotBytesReceived_lo = 0; > + fBaseExtSeqNumReceived = 0; > + fHighestExtSeqNumReceived = 0; > fHaveSeenInitialSequenceNumber = False; This will be fixed in the next release of the code (later today). Thanks for the report. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 5 10:19:48 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Apr 2013 10:19:48 -0700 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: <2C55BDC7C60FF64D894FC9E84A0B6F2E6FED9E64@BLSUSAEXCH1.fike.corp> References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> <8257FC57-4DA2-4D46-B7FA-60649657158A@live555.com> <2C55BDC7C60FF64D894FC9E84A0B6F2E6FED9E64@BLSUSAEXCH1.fike.corp> Message-ID: <0F233C26-E6F9-48EF-A73E-E8D7F707F67D@live555.com> > Could this problem be related to another issue I?ve recently had with using proxy server with vlc as the back end server. The RTSP session timeout is hardcoded to 60 secs in VLC . The VLC RTSP server does support GET_PARAMETER and PAUSE as shown in OPTIONS. But when live555 proxy client sends it a GET_PARAMETER the response is a 451 client error and on sending PAUSE sends backs 405 error. VLC Server ends up sending a RTCP Bye message and disconnects the session. No, this issue is not related, because the errors that we have been talking about here have been from 'back-end' servers that are network cameras - not "VLC". However, because you have apparently discovered a bug in VLC's RTSP server implementation (which, by the way, does *not* use the LIVE555 libraries), you should report this to the VLC developers. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 5 16:35:24 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Apr 2013 16:35:24 -0700 Subject: [Live-devel] Not receiving frames from H264 stream In-Reply-To: References: Message-ID: <35DF220E-56BE-499B-ADD2-AD16F2F7EE47@live555.com> > I should have finished working through the advice in the FAQ - openRTSP successfully streamed from my cameras with the -t option, and setting the fourth argument of setupSubsession() to true fixed my problems. > > I also found that I did not need to specify the video resolution in order to get a proper stream, so I would still be interested in a response to my second question. You asked: > > 2. Do I need to worry about the height and width parameters? I'm guessing they're included in maybe the sprop-parameter string, and this doesn't apply to H264 streams (or at least this stream) since VLC doesn't need to ask me for the resolution. That's correct. If you're streaming H.264, then this information (height & width) is included in the "sprop-parameter-string" (formed by the stream's SPS and PPS NAL units), so receiving media players should not need it to be specified separately. The same is true for most (but perhaps not all) other video codecs. However, if you are trying to save an incoming stream into a ".mov" (or ".mp4") or ".avi" file, then the height and width parameters (and also frame-rate) can help. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 5 17:10:23 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Apr 2013 17:10:23 -0700 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: <83B9617CAE5B45F9A1F79D52ECF9F25D@tbxpnotebook> References: <83B9617CAE5B45F9A1F79D52ECF9F25D@tbxpnotebook> Message-ID: <116624BF-DC40-4FA8-B616-C1C07B6F6827@live555.com> > I am experimenting with the testRTSPClient app to develop a DirectShow source filter to connect to a network camera outputting an H.264 > video stream. The app successfully connects to the camera and shows the following continuous output: > ... > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.117119 > Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 411 bytes. Presentation time: 1365102232.186298 > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.226244 > Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 458 bytes. Presentation time: 1365102232.375975 > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.359869 > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.465869 > Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.585744 > Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 950 bytes. Presentation time: 1365102232.666086 > ... > > Initially, I am only interested in the video portion of the stream. > Using the library, what is the most efficient way to get access to the H.264 portion of the stream Because this is a Frequently Asked Question, I have now added an entry for it to the FAQ. See: http://www.live555.com/liveMedia/faq.html#testRTSPClient-how-to-decode-data Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From louxkr at gmail.com Fri Apr 5 10:55:48 2013 From: louxkr at gmail.com (Kerry Loux) Date: Fri, 5 Apr 2013 13:55:48 -0400 Subject: [Live-devel] Determine NAL unit of H264 frame Message-ID: Hello, I'm trying to determine the NAL unit type of incoming H264 data in ::afterGettingFrame(). My goal is to send the data to ffmpeg, and I'm basing my approach on what is described in this thread: http://comments.gmane.org/gmane.comp.multimedia.live555.devel/7743 Can anyone point me in the right direction? I'm new to video-anything and am fumbling around just trying to get my bearings. Thanks, Kerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Fri Apr 5 12:28:39 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Fri, 5 Apr 2013 19:28:39 +0000 Subject: [Live-devel] Unitialized memory in RTPReceptionStats In-Reply-To: <4AFFA16A-5760-4708-88EB-F87CBB30324B@live555.com> References: <27885_1365167561_515ECDC9_27885_6183_2_1BE8971B6CFF3A4F97AF4011882AA25501561039B8DB@THSONEA01CMS01P.one.grp> <4AFFA16A-5760-4708-88EB-F87CBB30324B@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC2252E1AA8@IL-BOL-EXCH01.smartwire.com> Just an FYI. I have noticed that many items are not initialized on construction. Mostly this shows up during incomplete usage by the programmer, me, but it is important to note that the checks for null that are in the code fail when in DEBUG on Windows. GCC generally zero's things, Microsoft puts a sentinel value so it crashes and you can find those cases. This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, April 05, 2013 12:13 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Unitialized memory in RTPReceptionStats I know you don't like valgrind tool I *do* like "valgrind". The problem with it, however, is that it frequently reports 'errors' that aren't really errors. Therefore, I generally don't pay attention when people send me "valgrind" reports, unless they can also note a specific problem in the code that is causing these reports to be generated. But fortunately you have done this. A way to fix this is to initialize void RTPReceptionStats::init(u_int32_t SSRC) { fSSRC = SSRC; fTotNumPacketsReceived = 0; fTotBytesReceived_hi = fTotBytesReceived_lo = 0; + fBaseExtSeqNumReceived = 0; + fHighestExtSeqNumReceived = 0; fHaveSeenInitialSequenceNumber = False; This will be fixed in the next release of the code (later today). Thanks for the report. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 6 21:54:03 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 6 Apr 2013 21:54:03 -0700 Subject: [Live-devel] Determine NAL unit of H264 frame In-Reply-To: References: Message-ID: <200DD7E0-600E-4C06-9BE3-4D119B6A7DA6@live555.com> > I'm trying to determine the NAL unit type of incoming H264 data in ::afterGettingFrame(). It's easy. According to the H.264 specification, the "nal_unit_type" is the last 5 bits of the first byte of the NAL unit (i.e., of each 'frame' delivered). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 6 21:55:02 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 6 Apr 2013 21:55:02 -0700 Subject: [Live-devel] Unitialized memory in RTPReceptionStats In-Reply-To: <615FD77639372542BF647F5EBAA2DBC2252E1AA8@IL-BOL-EXCH01.smartwire.com> References: <27885_1365167561_515ECDC9_27885_6183_2_1BE8971B6CFF3A4F97AF4011882AA25501561039B8DB@THSONEA01CMS01P.one.grp> <4AFFA16A-5760-4708-88EB-F87CBB30324B@live555.com> <615FD77639372542BF647F5EBAA2DBC2252E1AA8@IL-BOL-EXCH01.smartwire.com> Message-ID: <0E093EB1-C99A-4789-93EB-8B61F268EB10@live555.com> > I have noticed that many items are not initialized on construction. > Mostly this shows up during incomplete usage by the programmer, me, but it is important to note that the checks for null that are in the code fail when in DEBUG on Windows. Have you found any examples of this in our code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Sat Apr 6 08:58:12 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Sat, 6 Apr 2013 15:58:12 +0000 Subject: [Live-devel] A question about thread safety. Message-ID: <615FD77639372542BF647F5EBAA2DBC2252E1CBB@IL-BOL-EXCH01.smartwire.com> I know live555 is an event model application and thread safety must be added if needed. I pull and record from hundreds of cameras. Because of some OS limitaitions I can only wait on a maximum of 64 events. So I have threads called processors for each group of 60 sources. Each of these has their own UsageEnvironment and TaskScheduler and event loop. Is this a reliable architecture? I do have an occasional access violation in Medium::~Medium() in units in the field, but today's problem is distinctly different. It only occurs with one brand of camera. Am I correct in assuming no camera, no matter how bad the stream, should be able to crash live555? The access violation always occurs in the same location. On the delete packet; line of ReorderingPacketBuffer::freePacket(BufferedPacket* packet){ if (packet != fSavedPacket) { delete packet; } else { fSavedPacketFree = True; } } In all inspections of memory the packet, whose pointer is not null, appears to already be destructed. The fBuf and vPtr are a special value 0xdddddddd which is Microsofts way of saying this memory was explicitly deleted. The call stack always shows we are a few frames down from MultiFramedRTPSource::networkReadHandler1() and I was trying to figure it out. I came across a question. Given the implementation of bytesAvailable() should the line "if bPacket->bytesavailable() == 0)..." be if bPacket->bytesavailable() <= 0)..." I am looking for suggestions on where to look for the source of this problem. Simple or scaled down examples do not have a problem. Valgrind like tools on windows have a high overhead and also seem to effect the occurrence. (Indicates a race!) Thanks Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Sun Apr 7 00:38:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 7 Apr 2013 00:38:55 -0700 Subject: [Live-devel] A question about (how to debug your crash) In-Reply-To: <615FD77639372542BF647F5EBAA2DBC2252E1CBB@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC2252E1CBB@IL-BOL-EXCH01.smartwire.com> Message-ID: I've changed the Subject: line of this email, because it's not clear what, if anything, your crash has to do with threads. > I pull and record from hundreds of cameras. Because of some OS limitaitions I can only wait on a maximum of 64 events. > > So I have threads called processors for each group of 60 sources. Each of these has their own UsageEnvironment and TaskScheduler and event loop. > > Is this a reliable architecture? Yes, provided that *all* of the following are true: 1/ No thread ever accesses a "LIVE555" object that was created by another thread. (The sole exception to this: A thread may call "triggerEvent()" on another thread's "TaskScheduler" object.) 2/ Your application code (that uses the LIVE555 libraries) is 'thread safe'. 3/ The system runtime library (that's used by both LIVE555 and your application code) is 'thread safe'. That's why if you want to have multiple threads of control, it's better, if possible, to give each thread of control its own process, rather than having multiple threads of control running in the same process. > today?s problem is distinctly different. > It only occurs with one brand of camera. What kind of camera is this? I.e., what codec(s) does it stream? Is there anything 'distinct' about it? > Am I correct in assuming no camera, no matter how bad the stream, should be able to crash live555? Yes, of course. Remember, though, that your application consists not just of the LIVE555 code, but also your application code, and the runtime libraries. A bug in any one of these might cause a crash that could (e.g., because it steps on a wrong piece of memory) give the appearance of being in the LIVE555 code. > The access violation always occurs in the same location. > On the delete packet; line of > ReorderingPacketBuffer::freePacket(BufferedPacket* packet){ > if (packet != fSavedPacket) { > delete packet; > } else { > fSavedPacketFree = True; > } > } > > In all inspections of memory the packet, whose pointer is not null, appears to already be destructed. The fBuf and vPtr are a special value 0xdddddddd which is Microsofts way of saying this memory was explicitly deleted. Your first task should be to make sure that you're running the latest version of the LIVE555 code. (I recently fixed a bug in the code that was causing symptoms similar (though not identical) to yours.) Your second task, IMHO, should be to figure out if "packet" *really* has already been deleted. One way to do this is to instrument both the constructor and destructor of "ReorderingPacketBuffer". E.g., add something like fprintf(stderr, "created ReorderingPacketBuffer:%p\n", this); to the "ReorderingPacketBuffer" constructor, and fprintf(stderr, "deleting ReorderingPacketBuffer:%p\n", this); to the "ReorderingPacketBuffer" destructor. Then, looking at your log after the crash, you'll be able to tell whether or not "packet" points to an actual "ReorderingPacketBuffer" object that had already been deleted. It's more likely, though, that "packet" will be a 'garbage' pointer - i.e., not pointing to a (currently or recently allocated) "ReorderingPacketBuffer". If this is the case, then the bug is that something must have (erroneously) written on top of the pointer. > The call stack always shows we are a few frames down from MultiFramedRTPSource::networkReadHandler1() and I was trying to figure it out. > I came across a question. Given the implementation of bytesAvailable() should the line ?if bPacket->bytesavailable() == 0)?? be if bPacket->bytesavailable() <= 0)?? No, because the "bytesAvailable()" function returns an unsigned value, i.e., always >= 0. This is almost certainly a 'red herring'. > I am looking for suggestions on where to look for the source of this problem. Simple or scaled down examples do not have a problem. Nonetheless, you should try to find the simplest possible environment that causes your crash. First, you should make sure that the (unmodified) "testRTSPClient" demo application does not crash when it streams from this network camera. Then, you should try running a single-threaded version of your application - first with just this single network camera as a source, then with more sources (up to your maximum of 60). If the single-threaded version of your application crashes - even once - then you will know that multi-threading in your application is not to blame. In any case, if the crash occurs only with your application (and not with (e.g.) "testRTSPClient"), then it's unlikely that I'll be able to debug it for free on this mailing list, unfortunately... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Mon Apr 8 04:20:49 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Mon, 8 Apr 2013 13:20:49 +0200 Subject: [Live-devel] build on mingw Message-ID: <23671_1365420051_5162A813_23671_11148_1_1BE8971B6CFF3A4F97AF4011882AA2550156104E5089@THSONEA01CMS01P.one.grp> Hi Ross, I update to your last release 2013.04.06 but build using mingw failed because isxdigit is unknown. Adding #include in RTSPCommon.cpp solve the problems. Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Mon Apr 8 07:09:23 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Mon, 8 Apr 2013 15:09:23 +0100 Subject: [Live-devel] live555ProxyServer freezes after upgrading from 2012.12.24 In-Reply-To: <0F233C26-E6F9-48EF-A73E-E8D7F707F67D@live555.com> References: <01395FB6-7713-49A5-8735-20F484EADB54@live555.com> <021DFAAB-0094-4150-8C07-BA5CFBEDD80B@live555.com> <8257FC57-4DA2-4D46-B7FA-60649657158A@live555.com> <2C55BDC7C60FF64D894FC9E84A0B6F2E6FED9E64@BLSUSAEXCH1.fike.corp> <0F233C26-E6F9-48EF-A73E-E8D7F707F67D@live555.com> Message-ID: Thanks a bunch Ross, the latest version 2013.04.06 doesn't exhibit any such problems with the cameras I have on test here. Everything is working beautifully! I will report if there are any problems. Thanks again for adding a workaround so quickly. On 5 April 2013 18:19, Ross Finlayson wrote: > Could this problem be related to another issue I?ve recently had with > using proxy server with vlc as the back end server. The RTSP session > timeout is hardcoded to 60 secs in VLC . The VLC RTSP server does support > GET_PARAMETER and PAUSE as shown in OPTIONS. But when live555 proxy client > sends it a GET_PARAMETER the response is a 451 client error and on sending > PAUSE sends backs 405 error. VLC Server ends up sending a RTCP Bye message > and disconnects the session. > > > No, this issue is not related, because the errors that we have been > talking about here have been from 'back-end' servers that are network > cameras - not "VLC". > > However, because you have apparently discovered a bug in VLC's RTSP server > implementation (which, by the way, does *not* use the LIVE555 libraries), > you should report this to the VLC developers. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 8 07:24:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Apr 2013 07:24:43 -0700 Subject: [Live-devel] build on mingw In-Reply-To: <23671_1365420051_5162A813_23671_11148_1_1BE8971B6CFF3A4F97AF4011882AA2550156104E5089@THSONEA01CMS01P.one.grp> References: <23671_1365420051_5162A813_23671_11148_1_1BE8971B6CFF3A4F97AF4011882AA2550156104E5089@THSONEA01CMS01P.one.grp> Message-ID: <511B8E3D-C789-42D3-A4C1-EC2979863168@live555.com> > I update to your last release 2013.04.06 but build using mingw failed because isxdigit is unknown. > Adding #include in RTSPCommon.cpp solve the problems. Thanks. This will be fixed in the next release of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amirguterman at gmail.com Mon Apr 8 12:29:00 2013 From: amirguterman at gmail.com (Amir Guterman) Date: Mon, 8 Apr 2013 22:29:00 +0300 Subject: [Live-devel] Need your professional opinion on upgrading our product to use your streaming technology Message-ID: Hi, I would like to receive your professional opinion on upgrading the current streaming technology that we use for our product today, by using your SDK's and libraries for streaming to mobile devices. *Brief* We are developing a product that will require a low-latency live video camera feed from home to a mobile device, in such way that the user will be able to look at the product at any given time as long as the product is located near a computer with a USB camera connected to it. So that generally the customers who buy our product, will also receive a software (for Mac or PC), that will stream their webcam or IP camera to their phone or tablet over 3G or WiFi, we will also provide an app for each mobile platform (Android, iOS, Windows Phone 8) that can play that stream. The server side should allow only to 1 client to play the stream at a time (encryption/authentication is an accepted solution for that matter) *Current technology in use* We are using Adobe Cirrus (aka Stratus) as the current technology for transferring low-latency h.264 p2p live video streaming packed in RTMFP protocol to mobile devices which support Adobe AIR such as Android smartphones and tablets, iPhone and iPad. This works perfectly, however, Adobe AIR platform is not supported on Windows Phone 8. We want to replace the Adobe technology, with any other solution that you can offer me that supports the video formats and protocols that are compatible with Android, iOS and WP8 enabled devices. *The modules that we need* *The server-side software:* Purpose - To stream the video feed from a camera device (e.g connected USB webcam or an IP camera on the local network), UI interface for changing the captured device, and connect to a db on a public server to keep track of the user's ip at home, so the mobile app will know where to connect. *On Mac:* We use XCode to develop cocoa UI application, that will interact/integrate with the modules that you'll provide me (hopefully) in Objective-C. *On PC:* We use Visual Studio .NET to develop the WinForm application, that will also interact/integrate with the modules that you'll provide me in a form of a API, SDK or even a command line utility (Java solution is also welcome). *The client-side app (iPhone/iPad/Android phones & tablets/WP8):* Purpose - To play the live video stream which broadcasted from home over 3G network as well as over WiFi. *For Android:* We use Eclipse and the ADT SDK. *For iOS:* We use XCode to develop the iPhone/iPad app. *For WP8:* We use Visual Studio 2012 for Windows Phone. * I assume that If we choose to work for example with H.264 or H.263 (3GPP, MPEG-4) which is supported in most operating systems and mobile devices, your solution will be to provide us with the SDK used for encoding and streaming the live video (from webcam) as a part of the server-side software, and we will use the core functions that come with each platform SDK (Android/iOS/WP8) for decoding and playing the specified stream. (e.g Android SDK has the VideoView class which is video player control that can play RTSP,MPEG-2, H.263, H.264 streams from a remote url) Best Regards, -- *Amir Guterman* -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 8 14:25:24 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Apr 2013 14:25:24 -0700 Subject: [Live-devel] Need your professional opinion on upgrading our product to use your streaming technology In-Reply-To: References: Message-ID: <6A879E72-0A1D-4C05-854B-3F933522FA61@live555.com> > We are developing a product Do "we" not have our own domain name? :-) (As stated clearly in the FAQ, people are taken a lot more seriously on this mailing list if they use a professional email address.) But anyway - It's important to understand that the "LIVE555 Streaming Media" software is primarily a set of software libraries, along with some simple console applications. Although it can be (and frequently has been) used to develop more complex, GUI-based applications, this requires a non-trivial amount of programming. Unless you are willing to undertake this programming yourself[*], you should instead look for other, pre-built solutions. Ross Finlayson Live Networks, Inc. http://www.live555.com/ [*] Although I am available for personal paid consulting (outside this mailing list) for companies that use the "LIVE555 Streaming Media" software, this generally does *not* include custom programming. In other words, although I may be able to help you after you have developed software that uses this software, this software development is something that you'll need to do yourself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tboonefisher at clear.net Mon Apr 8 14:06:25 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Mon, 8 Apr 2013 16:06:25 -0500 Subject: [Live-devel] Need your professional opinion on upgrading our product to use your streaming technology In-Reply-To: References: Message-ID: <10F849E2F04B4A129B1B058C396554FD@tbxpnotebook> Aren't such product(s) already available e.g. http://foscam.us/ and others? Tom Fisher From: Amir Guterman Sent: Monday, April 08, 2013 2:29 PM To: live-devel at ns.live555.com Subject: [Live-devel] Need your professional opinion on upgrading our product to use your streaming technology Hi, I would like to receive your professional opinion on upgrading the current streaming technology that we use for our product today, by using your SDK's and libraries for streaming to mobile devices. Brief We are developing a product that will require a low-latency live video camera feed from home to a mobile device, in such way that the user will be able to look at the product at any given time as long as the product is located near a computer with a USB camera connected to it. So that generally the customers who buy our product, will also receive a software (for Mac or PC), that will stream their webcam or IP camera to their phone or tablet over 3G or WiFi, we will also provide an app for each mobile platform (Android, iOS, Windows Phone 8) that can play that stream. The server side should allow only to 1 client to play the stream at a time (encryption/authentication is an accepted solution for that matter) Current technology in use We are using Adobe Cirrus (aka Stratus) as the current technology for transferring low-latency h.264 p2p live video streaming packed in RTMFP protocol to mobile devices which support Adobe AIR such as Android smartphones and tablets, iPhone and iPad. This works perfectly, however, Adobe AIR platform is not supported on Windows Phone 8. We want to replace the Adobe technology, with any other solution that you can offer me that supports the video formats and protocols that are compatible with Android, iOS and WP8 enabled devices. The modules that we need The server-side software: Purpose - To stream the video feed from a camera device (e.g connected USB webcam or an IP camera on the local network), UI interface for changing the captured device, and connect to a db on a public server to keep track of the user's ip at home, so the mobile app will know where to connect. On Mac: We use XCode to develop cocoa UI application, that will interact/integrate with the modules that you'll provide me (hopefully) in Objective-C. On PC: We use Visual Studio .NET to develop the WinForm application, that will also interact/integrate with the modules that you'll provide me in a form of a API, SDK or even a command line utility (Java solution is also welcome). The client-side app (iPhone/iPad/Android phones & tablets/WP8): Purpose - To play the live video stream which broadcasted from home over 3G network as well as over WiFi. For Android: We use Eclipse and the ADT SDK. For iOS: We use XCode to develop the iPhone/iPad app. For WP8: We use Visual Studio 2012 for Windows Phone. * I assume that If we choose to work for example with H.264 or H.263 (3GPP, MPEG-4) which is supported in most operating systems and mobile devices, your solution will be to provide us with the SDK used for encoding and streaming the live video (from webcam) as a part of the server-side software, and we will use the core functions that come with each platform SDK (Android/iOS/WP8) for decoding and playing the specified stream. (e.g Android SDK has the VideoView class which is video player control that can play RTSP,MPEG-2, H.263, H.264 streams from a remote url) Best Regards, -- Amir Guterman _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From amirguterman at gmail.com Mon Apr 8 14:32:36 2013 From: amirguterman at gmail.com (Amir Guterman) Date: Tue, 9 Apr 2013 00:32:36 +0300 Subject: [Live-devel] Need your professional opinion on upgrading our product to use your streaming technology In-Reply-To: <6A879E72-0A1D-4C05-854B-3F933522FA61@live555.com> References: <6A879E72-0A1D-4C05-854B-3F933522FA61@live555.com> Message-ID: Hi Ross, I am planning on doing the programming myself, I was just asking if LIVE555 is generally the way to go for my requirements. Thank's! On Tue, Apr 9, 2013 at 12:25 AM, Ross Finlayson wrote: > We are developing a product > > > Do "we" not have our own domain name? :-) (As stated clearly in the FAQ, > people are taken a lot more seriously on this mailing list if they use a > professional email address.) > > But anyway - It's important to understand that the "LIVE555 Streaming > Media" software is primarily a set of software libraries, along with some > simple console applications. Although it can be (and frequently has been) > used to develop more complex, GUI-based applications, this requires a > non-trivial amount of programming. Unless you are willing to undertake > this programming yourself[*], you should instead look for other, pre-built > solutions. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > [*] Although I am available for personal paid consulting (outside this > mailing list) for companies that use the "LIVE555 Streaming Media" > software, this generally does *not* include custom programming. In other > words, although I may be able to help you after you have developed software > that uses this software, this software development is something that you'll > need to do yourself. > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -- *Amir Guterman* -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 8 23:07:11 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Apr 2013 23:07:11 -0700 Subject: [Live-devel] A summary of the survey responses, FYI Message-ID: <6EADE112-1904-4074-8EA9-C42D07C3140E@live555.com> Thanks to the 152 of you who took our survey: 'Your use of the "LIVE555 Streaming Media" software'. As promised, the details of individual responses will remain confidential. However, here, FYI, is a summary of the major questions of the survey. 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: q1.jpg Type: image/jpg Size: 45528 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: q2.jpg Type: image/jpg Size: 50459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: q4.jpg Type: image/jpg Size: 67932 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: q5.jpg Type: image/jpg Size: 57220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: q7.jpg Type: image/jpg Size: 57930 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: q8.jpg Type: image/jpg Size: 57970 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qa.jpg Type: image/jpg Size: 47265 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qb.jpg Type: image/jpg Size: 52812 bytes Desc: not available URL: From jshanab at smartwire.com Tue Apr 9 04:02:22 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Tue, 9 Apr 2013 11:02:22 +0000 Subject: [Live-devel] Need your professional opinion on upgrading our product to use your streaming technology In-Reply-To: References: <6A879E72-0A1D-4C05-854B-3F933522FA61@live555.com>, Message-ID: <615FD77639372542BF647F5EBAA2DBC2252E2403@IL-BOL-EXCH01.smartwire.com> We have a product that uses live555 along with libavcodec to play streams from IP cameras to mobile devices,browsers and an archiver/restreamer. Using live555 in some environments means you are not using the built in libraries and therfore not hooked into their hardware decoder. But a single IP camera at D1 resolution is ok up to 15fps on older android and 30fps on iphone and newer droids. Note this limitation is NOT live555, it is access to the decoder. Colorspace conversion and scaling take as much CPU as H264 decoding so I shift that to the opengl hardware with shaders. I also have built the proxy server and an app based on that to restream 4 cameras (d1 at 30fps) on a Raspberry PI. I let it run 72 hours and it only used 9% CPU. The raspberry PI is a credit card sized SBC that is like an older phone in power (700mhz arm) Our app is not peer to peer but I have thought about doing it. The trick is the firewall issues. I push out past a firewall with the raspberry pi and any client including mobile can connect then to that restream server. The external server archives and allows multiple client connections, but adds latency. I need to buy a windows phone and port our phone app to it next! ________________________________ From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] on behalf of Amir Guterman [amirguterman at gmail.com] Sent: Monday, April 08, 2013 4:32 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Need your professional opinion on upgrading our product to use your streaming technology Hi Ross, I am planning on doing the programming myself, I was just asking if LIVE555 is generally the way to go for my requirements. Thank's! This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. On Tue, Apr 9, 2013 at 12:25 AM, Ross Finlayson > wrote: We are developing a product Do "we" not have our own domain name? :-) (As stated clearly in the FAQ, people are taken a lot more seriously on this mailing list if they use a professional email address.) But anyway - It's important to understand that the "LIVE555 Streaming Media" software is primarily a set of software libraries, along with some simple console applications. Although it can be (and frequently has been) used to develop more complex, GUI-based applications, this requires a non-trivial amount of programming. Unless you are willing to undertake this programming yourself[*], you should instead look for other, pre-built solutions. Ross Finlayson Live Networks, Inc. http://www.live555.com/ [*] Although I am available for personal paid consulting (outside this mailing list) for companies that use the "LIVE555 Streaming Media" software, this generally does *not* include custom programming. In other words, although I may be able to help you after you have developed software that uses this software, this software development is something that you'll need to do yourself. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -- Amir Guterman -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel.orenes at displaynote.com Tue Apr 9 07:03:33 2013 From: miguel.orenes at displaynote.com (Miguel Orenes) Date: Tue, 9 Apr 2013 14:03:33 +0000 Subject: [Live-devel] Problem to transform mp4 (AAC, H264) to Elementary h264 Message-ID: Hi everyone. I am trying to send a video file recorded on Android to a media server by using "testMPEG2TransportStreamer.cpp" later to create the TS file by using "testH264VideoToTransportStream.cpp" to an own media server. I copied the video to my PC in order to avoid problems with live555 on Android, step by step :). I know that "testH264VideoToTransportStream + testMPEG2TransportStreamer " works fine because I downloaded "slamtv60.264" from live555.com and sent out.ts, resulted from "testH264VideoToTransportStream", by "testMPEG2TransportStreamer" to my media server and could play the live stream in VLC (on windows) and Android *without* problems in the same time(as a media server must do). Then, my problem is that I am not able to transform my Android video to an *elementary h264* file. In this moment my code is the next: void createH264ElementaryFile() { // Begin by setting up our usage environment: TaskScheduler* scheduler = BasicTaskScheduler::createNew(); env = BasicUsageEnvironment::createNew(*scheduler); // Open the input file as a 'byte-stream file source': FramedSource* inputSource = ByteStreamFileSource::createNew(*env, inputFileName); if (inputSource == NULL) { *env << "Unable to open file \"" << inputFileName << "\" as a byte-stream file source\n"; exit(1); } // Open the output file as a 'file sink': H264VideoFileSink* outputSink = H264VideoFileSink::createNew(*env, h264FileSink); if (outputSink == NULL) { *env << "Unable to open file \"" << h264FileSink << "\" as a file sink\n"; exit(1); } // Finally, start playing: *env << "Beginning to read...\n"; outputSink->startPlaying(*inputSource, afterPlayingcreateH264ElementaryFile, NULL); env->taskScheduler().doEventLoop(); // does not return } I read that I need to insert before each NAL unit an start code (0x00000001), then I think I need to develop a "H264FramedSource" in order to insert the code, but I am not able to find an example or a tip to implement a solution. Any suggestions? Many thanks!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 9 07:32:21 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Apr 2013 07:32:21 -0700 Subject: [Live-devel] Problem to transform mp4 (AAC, H264) to Elementary h264 In-Reply-To: References: Message-ID: Sorry, but we currently don't have any software for 'demultiplexing' ".mp4"-format files. Therefore, you can't use our libraries to process your file. Some other library - e.g., "ffmpeg" - might work for you, however. (Alternatively, if you can record your file with the 'Matroska' (i.e., ".mkv") file format, then you could use our software to demultiplex such a file (or just stream from it directly).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amirguterman at gmail.com Tue Apr 9 07:45:11 2013 From: amirguterman at gmail.com (Amir Guterman) Date: Tue, 9 Apr 2013 17:45:11 +0300 Subject: [Live-devel] Need your professional opinion on upgrading our product to use your streaming technology In-Reply-To: <615FD77639372542BF647F5EBAA2DBC2252E2403@IL-BOL-EXCH01.smartwire.com> References: <6A879E72-0A1D-4C05-854B-3F933522FA61@live555.com> <615FD77639372542BF647F5EBAA2DBC2252E2403@IL-BOL-EXCH01.smartwire.com> Message-ID: Sorry, this is not what I am looking for, for that matter I could use wowza or FMS. I use upnp port forwarding to overcome the NAT issues. I am looking for an encoder developer tool or a utility like ffmpeg. or API (not web API's) On Tue, Apr 9, 2013 at 2:02 PM, Jeff Shanab wrote: > We have a product that uses live555 along with libavcodec to play > streams from IP cameras to mobile devices,browsers and an > archiver/restreamer. > > Using live555 in some environments means you are not using the built in > libraries and therfore not hooked into their hardware decoder. But a single > IP camera at D1 resolution is ok up to 15fps on older android and 30fps on > iphone and newer droids. Note this limitation is NOT live555, it is access > to the decoder. Colorspace conversion and scaling take as much CPU as H264 > decoding so I shift that to the opengl hardware with shaders. > > I also have built the proxy server and an app based on that to restream 4 > cameras (d1 at 30fps) on a Raspberry PI. I let it run 72 hours and it only > used 9% CPU. The raspberry PI is a credit card sized SBC that is like an > older phone in power (700mhz arm) > > Our app is not peer to peer but I have thought about doing it. The trick > is the firewall issues. I push out past a firewall with the raspberry pi > and any client including mobile can connect then to that restream server. > The external server archives and allows multiple client connections, but > adds latency. > > I need to buy a windows phone and port our phone app to it next! > ------------------------------ > *From:* live-devel-bounces at ns.live555.com [ > live-devel-bounces at ns.live555.com] on behalf of Amir Guterman [ > amirguterman at gmail.com] > *Sent:* Monday, April 08, 2013 4:32 PM > *To:* LIVE555 Streaming Media - development & use > *Subject:* Re: [Live-devel] Need your professional opinion on upgrading > our product to use your streaming technology > > Hi Ross, > I am planning on doing the programming myself, I was just asking if > LIVE555 is generally the way to go for my requirements. > > Thank's! > > > > > > > This message and any attachments contain confidential and proprietary > information, and may contain privileged information, belonging to one or > more affiliates of Windy City Wire Cable & Technology Products, LLC. No > privilege is waived by this transmission. Unauthorized use, copying or > disclosure of such information is prohibited and may be unlawful. If you > receive this message in error, please delete it from your system, destroy > any printouts or copies of it, and notify the sender immediately by e-mail > or phone. > > On Tue, Apr 9, 2013 at 12:25 AM, Ross Finlayson wrote: > >> We are developing a product >> >> >> Do "we" not have our own domain name? :-) (As stated clearly in the >> FAQ, people are taken a lot more seriously on this mailing list if they use >> a professional email address.) >> >> But anyway - It's important to understand that the "LIVE555 Streaming >> Media" software is primarily a set of software libraries, along with some >> simple console applications. Although it can be (and frequently has been) >> used to develop more complex, GUI-based applications, this requires a >> non-trivial amount of programming. Unless you are willing to undertake >> this programming yourself[*], you should instead look for other, pre-built >> solutions. >> >> Ross Finlayson >> Live Networks, Inc. >> http://www.live555.com/ >> >> [*] Although I am available for personal paid consulting (outside this >> mailing list) for companies that use the "LIVE555 Streaming Media" >> software, this generally does *not* include custom programming. In other >> words, although I may be able to help you after you have developed software >> that uses this software, this software development is something that you'll >> need to do yourself. >> >> >> _______________________________________________ >> live-devel mailing list >> live-devel at lists.live555.com >> http://lists.live555.com/mailman/listinfo/live-devel >> >> > > > -- > *Amir Guterman* > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -- *Amir Guterman* -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel.orenes at displaynote.com Tue Apr 9 08:24:42 2013 From: miguel.orenes at displaynote.com (Miguel Orenes) Date: Tue, 9 Apr 2013 15:24:42 +0000 Subject: [Live-devel] Problem to transform mp4 (AAC, H264) to Elementary h264 In-Reply-To: References: Message-ID: Thanks Ross for your answer and your suggestion, but unfortunately Matroska is only available for Android 4.0+ and I think ffmpeg doesn't allow real time demultiplexing. I will try by other way. Thanks! From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, April 9, 2013 4:32 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Problem to transform mp4 (AAC, H264) to Elementary h264 Sorry, but we currently don't have any software for 'demultiplexing' ".mp4"-format files. Therefore, you can't use our libraries to process your file. Some other library - e.g., "ffmpeg" - might work for you, however. (Alternatively, if you can record your file with the 'Matroska' (i.e., ".mkv") file format, then you could use our software to demultiplex such a file (or just stream from it directly).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tboonefisher at clear.net Tue Apr 9 13:55:49 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Tue, 9 Apr 2013 15:55:49 -0500 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream Message-ID: Reading further on your site I see that you may need the SDP description from my camera stream. BTW, I am getting some very jerky but clear video frames just by passing the NAL units directly to a MS DTV-DVD Video Decoder filter in DirectShow. I am soooooo close! v=0 o=- 1365522147122142 1 IN IP4 192.168.1.2 s=IP Camera Video i=videoMain t=0 0 a=tool:LIVE555 Streaming Media v2013.01.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:IP Camera Video a=x-qt-text-inf:videoMain m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 H264/90000 a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 b=AS:64 a=control:track2 Thanks again for any help. Tom Fisher From: tboonefisher at clear.net Sent: Tuesday, April 09, 2013 2:41 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream THANKS for the help. Reading the FAQ I see: ? If you are receiving H.264 video data, there is one more thing that you have to do before you start feeding frames to your decoder. 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()" (defined in the file "include/H264VideoRTPSource.hh"), to generate binary NAL units for your decoder.? Could you be more specific as to when/where that this needs to be done? Using the DummySink example, when I attempt to call these methods as shown below I get nada... DummySink::DummySink(UsageEnvironment& env, MediaSubsession& subsession, char const* streamId) : MediaSink(env), fSubsession(subsession) { fStreamId = strDup(streamId); fReceiveBuffer = new u_int8_t[DUMMY_SINK_RECEIVE_BUFFER_SIZE]; const char* sps = fSubsession.fmtp_spropparametersets(); /// returns NULL unsigned n_records=0; SPropRecord* pSPropRecord = parseSPropParameterSets( fSubsession.fmtp_spropparametersets(), n_records ); } Thanks again for ANY help... Tom Fisher From: Ross Finlayson Sent: Friday, April 05, 2013 7:10 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream I am experimenting with the testRTSPClient app to develop a DirectShow source filter to connect to a network camera outputting an H.264 video stream. The app successfully connects to the camera and shows the following continuous output: ... Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.117119 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 411 bytes. Presentation time: 1365102232.186298 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.226244 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 458 bytes. Presentation time: 1365102232.375975 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.359869 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.465869 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.585744 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 950 bytes. Presentation time: 1365102232.666086 ... Initially, I am only interested in the video portion of the stream. Using the library, what is the most efficient way to get access to the H.264 portion of the stream Because this is a Frequently Asked Question, I have now added an entry for it to the FAQ. See: http://www.live555.com/liveMedia/faq.html#testRTSPClient-how-to-decode-data Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 9 15:38:33 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Apr 2013 15:38:33 -0700 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: References: Message-ID: <703D9348-EEAE-4F60-8ECE-A15F22D86640@live555.com> > Reading further on your site I see that you may need the SDP description > from my camera stream. [...] > v=0 > o=- 1365522147122142 1 IN IP4 192.168.1.2 > s=IP Camera Video > i=videoMain > t=0 0 > a=tool:LIVE555 Streaming Media v2013.01.25 > a=type:broadcast > a=control:* > a=range:npt=0- > a=x-qt-text-nam:IP Camera Video > a=x-qt-text-inf:videoMain > m=video 0 RTP/AVP 96 > c=IN IP4 0.0.0.0 > b=AS:96 > a=rtpmap:96 H264/90000 > a=control:track1 > m=audio 0 RTP/AVP 0 > c=IN IP4 0.0.0.0 > b=AS:64 > a=control:track2 OK, the bug here is in your server - i.e., the camera; not the client. The camera (server) isn't including a "sprop-parameter-strings" parameter (in a "a=fmtp:96..." line) in the SDP description. Fortunately, however, I see that the camera (server) is also implemented using our software, so it should be easy to fix. Please tell whoever developed your camera to: (1) Upgrade to the latest version of the "LIVE555 Streaming Media" software, and (2) Either insert "SPS" and "PPS" NAL units at the start of the H.264 Video stream (that it feeds into the "H264VideoRTPSink" object, or else change the way that the "H264VideoRTPSink" object is created - to use one of the forms of the "H264VideoRTPSink::createNew()" function that take "SPS"/"PPS" NAL unit information as a parameter (either as raw binary NAL units, or a "sPropParameterSetsStr" string). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tboonefisher at clear.net Tue Apr 9 16:15:07 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Tue, 9 Apr 2013 18:15:07 -0500 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream Message-ID: It must also be VERY frustrating to see these companies making $$$$$$$ from your very nice work !!! Tom Fisher -----Original Message----- From: tboonefisher at clear.net Sent: Tuesday, April 09, 2013 6:05 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream This is BAD news as the camera is: http://foscam.us/products/foscam-fi9821w-megapixel-wireless-ip-camera.html I am just an end-user and thus probably have little influence on them. I will send them the info that you suggest but I will be very surprised IF they respond. They have their own ?plug-in? that works pretty well in IE and other apps. Are there any other possible work-arounds? Is possible that they are using MEDIASUBTYPE_AVC1 'AVC1' H.264(without start codes)? I did try this(GetMediatype()), but I have no decoders that will connect to that.....ughhhhhh. Thanks very much for your help... Tom Fisher Dallas From: Ross Finlayson Sent: Tuesday, April 09, 2013 5:38 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream Reading further on your site I see that you may need the SDP description from my camera stream. [...] v=0 o=- 1365522147122142 1 IN IP4 192.168.1.2 s=IP Camera Video i=videoMain t=0 0 a=tool:LIVE555 Streaming Media v2013.01.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:IP Camera Video a=x-qt-text-inf:videoMain m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 H264/90000 a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 b=AS:64 a=control:track2 OK, the bug here is in your server - i.e., the camera; not the client. The camera (server) isn't including a "sprop-parameter-strings" parameter (in a "a=fmtp:96..." line) in the SDP description. Fortunately, however, I see that the camera (server) is also implemented using our software, so it should be easy to fix. Please tell whoever developed your camera to: (1) Upgrade to the latest version of the "LIVE555 Streaming Media" software, and (2) Either insert "SPS" and "PPS" NAL units at the start of the H.264 Video stream (that it feeds into the "H264VideoRTPSink" object, or else change the way that the "H264VideoRTPSink" object is created - to use one of the forms of the "H264VideoRTPSink::createNew()" function that take "SPS"/"PPS" NAL unit information as a parameter (either as raw binary NAL units, or a "sPropParameterSetsStr" string). 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 Tue Apr 9 17:04:38 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Apr 2013 17:04:38 -0700 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: References: Message-ID: <18DC3F3D-1E58-4DEF-A766-83516D2F79BB@live555.com> > It must also be VERY frustrating to see these companies making $$$$$$$ > from your very nice work !!! On the contrary - I am *happy* to see many companies making successful use of this software. That's why I made it available. > This is BAD news as the camera is: > > http://foscam.us/products/foscam-fi9821w-megapixel-wireless-ip-camera.html What does frustrate me, however, is that so many of the companies that have successfully used this software in their products have avoided making use of the support offered by this mailing list. In particular, nobody from "Foscam" appears to be on this mailing list. > I am just an end-user and thus probably have little influence on them. I > will send them > the info that you suggest but I will be very surprised IF they respond. Please also check whether you have the latest firmware for your camera. Firmware upgrades for Foscam camera can apparently be downloaded from: http://foscam.us/firmware > Are there any other possible work-arounds? No. The problem is with the camera. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Wed Apr 10 06:12:12 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Wed, 10 Apr 2013 15:12:12 +0200 Subject: [Live-devel] presentationTime send by RTSPServer Message-ID: <17120_1365599540_51656534_17120_4168_1_1BE8971B6CFF3A4F97AF4011882AA2550156106F2314@THSONEA01CMS01P.one.grp> Hi Ross, I come back on the subject of sending presentationTime from a live555 RTSP server to a live555 RTSP client. Till now I have missed that RTCP sendReport were always based on server clock and basically the presentationTime set by an RTPSink is more or less ignored. I hope it's not a will ? I made some experiences in order to propagate the presentationTime : - adding a method in RTPSink in order to initialize fInitialPresentationTime & fMostRecentPresentationTime - build the SR report based on fMostRecentPresentationTime if it is set This allow user to use an overloaded OnDemandServerMediaSubSession::startStream to initialize the presentationTime that will be used by the RTCPInstance::sendReport. Do you think it could be a way to send frame time from RTSP server to RTSP client ? Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: setPresentationTime.patch Type: application/octet-stream Size: 3812 bytes Desc: setPresentationTime.patch URL: From finlayson at live555.com Wed Apr 10 07:51:45 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Apr 2013 07:51:45 -0700 Subject: [Live-devel] presentationTime send by RTSPServer In-Reply-To: <17120_1365599540_51656534_17120_4168_1_1BE8971B6CFF3A4F97AF4011882AA2550156106F2314@THSONEA01CMS01P.one.grp> References: <17120_1365599540_51656534_17120_4168_1_1BE8971B6CFF3A4F97AF4011882AA2550156106F2314@THSONEA01CMS01P.one.grp> Message-ID: > I come back on the subject of sending presentationTime from a live555 RTSP server to a live555 RTSP client. > Till now I have missed that RTCP sendReport were always based on server clock and basically the presentationTime set by an RTPSink is more or less ignored. No, the presentation time that is fed to (not 'set by') a server's "RTPSink" is NOT 'ignored' It's never ignored. HOWEVER, as I have REPEATEDLY said on this mailing list, if the server is built using our code, then these presentation times (the ones that are fed to "RTPSink"s) must be aligned with 'wall clock' time - i.e., the times that are sent using "gettimeofday()". In other words, the data source objects that feed to "RTPSink"s must have their presentation times properly aligned with 'wall clock' time. I don't know what your 'patch' allegedly does (because I don't know why/where your proposed new "RTPSink::setPresentationTImes()" function would ever be called, but I don't care, because presentation times are not 'set' for "RTPSink"s; they are fed to "RTPSink"s). In any case, I won't be applying your patch, because nothing is broken. > Do you think it could be a way to send frame time from RTSP server to RTSP client ? I simply fail to understand why you keep talking about 'sending times from the server to the client', because that's ALREADY WHAT WE DO (and have done for years)! However (again, as I have explained REPEATEDLY), all clients must be prepared for the possibility that the first few client-generated presentation times (before RTCP synchronization has occurred) will not be accurate. HOWEVER, as of version 2013.03.23, our server implementation (but, of course, not necessarily other people's server implementations) sends a RTCP "SR" packet before the first RTP packet. This makes it very likely (though never certain, due to possible packet loss) that the clients presentation times will all be RTCP-synchronized. I did this specifically to make you happy - or so I thought... (Unfortunately, I'm going to have to moderate all future posts from you, because I'm tired of the mailing list being filled with your confused messages, and I'm tired of explaining the same thing over and over again.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccaughie at openeye.net Wed Apr 10 10:26:15 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Wed, 10 Apr 2013 10:26:15 -0700 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: <18DC3F3D-1E58-4DEF-A766-83516D2F79BB@live555.com> References: <18DC3F3D-1E58-4DEF-A766-83516D2F79BB@live555.com> Message-ID: <853C62832D606043A043BD770304786C0424A6FA@EDD.pcopen.net> I've also worked with cameras that don't send sprop-parameter-sets in the SDP file (but not using the Live555 client); this shouldn't be a problem as long as the camera does send SPS and PPS in band. The fact that you are able to decode and display the raw NALUs using DirectShow would indicate that it is (decoding would fail otherwise), so perhaps your problem is elsewhere? Colin Caughie Chief Software Architect (509) 232-5261 ext 5914 What is heroic customer service? ** NOTICE ** The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, April 09, 2013 5:05 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream It must also be VERY frustrating to see these companies making $$$$$$$ from your very nice work !!! On the contrary - I am *happy* to see many companies making successful use of this software. That's why I made it available. This is BAD news as the camera is: http://foscam.us/products/foscam-fi9821w-megapixel-wireless-ip-camera.ht ml What does frustrate me, however, is that so many of the companies that have successfully used this software in their products have avoided making use of the support offered by this mailing list. In particular, nobody from "Foscam" appears to be on this mailing list. I am just an end-user and thus probably have little influence on them. I will send them the info that you suggest but I will be very surprised IF they respond. Please also check whether you have the latest firmware for your camera. Firmware upgrades for Foscam camera can apparently be downloaded from: http://foscam.us/firmware Are there any other possible work-arounds? No. The problem is with the camera. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 10 11:05:19 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Apr 2013 11:05:19 -0700 Subject: [Live-devel] NOTE: Code modification, subclassing, and the LGPL Message-ID: One of the surprising findings from the recent survey was that so many responders (more than 30%) reported that they needed to "modify" the LIVE555 source code for their purposes. Looking at the specific details of their reported "modifications", however, it became clear that many people were confused about what it means to "modify" the supplied "LIVE555 Streaming Media" code. In particular, many people described their "modifications" by explaining that they needed to create their own subclasses of existing LIVE555 classes. Subclassing an object-oriented library is *not* modifying it. On the contrary, it's the appropriate and proper way to extend its functionality. You can subclass an existing LIVE555 class without changing *any* of the LIVE555 files (either the ".hh" or ".cpp" files). Because the existing LIVE555 files remain unchanged, it's trivial to upgrade to a new version of the code, whenever it comes out. More importantly, if you subclass the LIVE555 classes - without modifying any of the LIVE555 header files or ".cpp" files - then, under the terms of the LGPL, you are *not* required to release your subclass code (nor the rest of your application code). Your application can be 'closed source'. If, however, you truly modify (i.e., change) the supplied LIVE555 library code - either the ".hh" or the ".cpp" files - and distribute a product (e.g., a network camera, media server, media player, or proxy server) that's built from this modified code, then, under the terms of the LGPL license (and the GPL license on which it is based), you MUST ALSO distribute your modifications to the LIVE555 code. ONCE AGAIN, TO MAKE THIS CLEAR: If you distribute a product (even a free product) that's based on a modified version of the LIVE555 code, then I MUST INSIST that you also distribute your modifications. The easiest way to do this is by putting your modifications on your product's web site. Note that merely sending your code modifications to the "live-devel" mailing list (even in the form of a 'patch' file) is NOT sufficient - unless your patch happens to get included in a future release of the LIVE555 code, and you then upgrade to this new version of the code (without modifying it again). But there's no guarantee that we will accept your patch (and we are certainly under no obligation to do so). We are unlikely to accept very large patches, nor patches that add functionality that's not likely to be of general interest. (Of course, patches that fix genuine bugs are always welcome.) As always, we will continue to try to design the LIVE555 library code in a way that makes it easy for developers to extend its functionality - if necessary - via subclassing. If you believe that a particular member function or variable should be "protected:" or even "public:" instead of "private:" (or "public:" instead of "protected:") then let us know. (Be aware, however, that not every such request will be accepted, because by design, some member functions and variables were truly not intended to be accessible to subclasses, or accessible from outside the class hierarchy.) A FINAL NOTE: If you have any further questions about your compliance with the LGPL and its conditions, please consult your company's copyright attorney. (This mailing list is filled with engineers, not lawyers, so it's not an appropriate forum for legal discussion.) If, after consulting your company's copyright attorney, you feel that you have problems complying with the LGPL, then please get in touch with me by private email (i.e., not via this mailing list), and we'll see what we can work out. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglan at yahoo.com Wed Apr 10 06:49:16 2013 From: zanglan at yahoo.com (Lan Zang) Date: Wed, 10 Apr 2013 21:49:16 +0800 (CST) Subject: [Live-devel] RTP over TCP packet size determination Message-ID: <1365601756.63835.YahooMailNeo@web15801.mail.cnb.yahoo.com> Hi, I sent the audio and video muxed in MPEG2TS container to an mobile phone(Android) via live555. The traffic from Live555 server to phone is via RTP over TCP, for the mobile phone is behind a NAT gateway. It goes well until I was request to send audio data only. Because that the bitrate for audio only stream is rather lower, the receiver running on mobile phone meets a jittering of the RTP/TCP stream as large as 3 seconds. I found if I split the packet into rather smaller size, the receiver's jittering situation is improved. So, I just want to see if I can change some parameters inside the server, so, the Live555 can send out smaller size packets? I found there is line47 in MultipleFramedSink.cpp: setPacketSizes(1000, 1448); If I changed the value to smaller one, like (256, 400), the packet size keeps the same size(~1300).? Regards, Lan Zang(Sander) From tboonefisher at clear.net Wed Apr 10 12:32:06 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Wed, 10 Apr 2013 14:32:06 -0500 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: <853C62832D606043A043BD770304786C0424A6FA@EDD.pcopen.net> References: <18DC3F3D-1E58-4DEF-A766-83516D2F79BB@live555.com> <853C62832D606043A043BD770304786C0424A6FA@EDD.pcopen.net> Message-ID: <3140F4E173D64B08951B5A8B85CC1942@tbxpnotebook> Thanks Colin. The fact that I do get some very jerky but clear video rendered, does make me suspicious that I?m not implementing my DS source filter correctly. In particular I?m looking closely at GetMediaType(..), etc method(s). As I said, my skills are weak/intermediate in this stuff, so any tips from the ?Pros? are greatly appreciated. Question...is it OK for me to post some of my DirectShow code here so that you might be able so see if/where I?m going wrong ??? Tom Fisher From: Colin Caughie Sent: Wednesday, April 10, 2013 12:26 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream I?ve also worked with cameras that don?t send sprop-parameter-sets in the SDP file (but not using the Live555 client); this shouldn?t be a problem as long as the camera does send SPS and PPS in band. The fact that you are able to decode and display the raw NALUs using DirectShow would indicate that it is (decoding would fail otherwise), so perhaps your problem is elsewhere? Colin Caughie Chief Software Architect (509) 232-5261 ext 5914 What is heroic customer service? ** NOTICE ** The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, April 09, 2013 5:05 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream It must also be VERY frustrating to see these companies making $$$$$$$ from your very nice work !!! On the contrary - I am *happy* to see many companies making successful use of this software. That's why I made it available. This is BAD news as the camera is: http://foscam.us/products/foscam-fi9821w-megapixel-wireless-ip-camera.html What does frustrate me, however, is that so many of the companies that have successfully used this software in their products have avoided making use of the support offered by this mailing list. In particular, nobody from "Foscam" appears to be on this mailing list. I am just an end-user and thus probably have little influence on them. I will send them the info that you suggest but I will be very surprised IF they respond. Please also check whether you have the latest firmware for your camera. Firmware upgrades for Foscam camera can apparently be downloaded from: http://foscam.us/firmware Are there any other possible work-arounds? No. The problem is with the camera. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------------------------------------------------------------------------- _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 10 16:49:01 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Apr 2013 16:49:01 -0700 Subject: [Live-devel] RTP over TCP packet size determination In-Reply-To: <1365601756.63835.YahooMailNeo@web15801.mail.cnb.yahoo.com> References: <1365601756.63835.YahooMailNeo@web15801.mail.cnb.yahoo.com> Message-ID: <3667A5E3-9A0A-4D98-BD6C-0A45332A2073@live555.com> > If I changed the value to smaller one, like (256, 400), the packet size keeps the same size(~1300). Calling "setPacketSizes(256,400)" on the newly-created "MultiFramedRTPSink" object should work. You shouldn't modify the supplied code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Scholz at dlr.de Thu Apr 11 01:38:54 2013 From: Michael.Scholz at dlr.de (Michael.Scholz at dlr.de) Date: Thu, 11 Apr 2013 08:38:54 +0000 Subject: [Live-devel] openRTSP-captured mp4 broken Message-ID: Moin to everybody! I played with the testProgs for a few days under Linux and Windows and also built a custom application which is still not working as it should. The FAQ helped in the beginning but not anymore. I already get problems when recording a H264/AAC stream (1280x720, 25 fps, key frame every 1/4 s, 2048 kb/s video, 96 kb/s audio) from an ABUS network camera with: ./openRTSP -d 8 -4 -w 1280 -h 720 -f 25 -y -H rtsp://192.168.1.10/live2.sdp > output_linux.mp4 Capturing works with the Linux- and Windows-compiled version, but only the Linux-mp4 is playable (playing the Windows- mp4 ffplay exits with "Invalid data found when processing input"). Though playing the Linux-mp4 with ffmpeg (ffplay) I get permanently some "no frame"-errors. Playing it with VLC the audio is cracking and runs longer than the 8 s of video. Further ffplay states that my video comes with 32.29 fps (not 25) and 2451 kb/s (not 2048). On the other hand, when I capture my stream with VLC or ffmpeg, the result is clean and nice to play with various players and the stream-properties correspond with the camera-settings. Am I correct to think that openRTSP should transcode the raw streams correctly using the -4 option? Or is this still the point where I have to work on? Why are my files recorded under Windows not playable at all? Thanks a lot! Michi From finlayson at live555.com Thu Apr 11 01:57:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Apr 2013 01:57:07 -0700 Subject: [Live-devel] openRTSP-captured mp4 broken In-Reply-To: References: Message-ID: <7942F389-4D79-4863-91A9-07FA3C395B09@live555.com> > Am I correct to think that openRTSP should transcode the raw streams correctly using the -4 option? In principle, yes (except that our code doesn't do any "transcoding"; it just records already-encoded data). However, this is difficult to do well, because the ".mp4" file format is ill-suited for what we are trying to do here: Record a file that properly represents incoming audio and video frames that are time-stamped. But undoubtedly this is one part of our code that could be improved. But if you're interested in trying to improve this, the code to look at is our implementation of the "QuickTimeFileSink" class - i.e., "liveMedia/QuickTimeFileSink.cpp". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Scholz at dlr.de Thu Apr 11 02:14:38 2013 From: Michael.Scholz at dlr.de (Michael.Scholz at dlr.de) Date: Thu, 11 Apr 2013 09:14:38 +0000 Subject: [Live-devel] openRTSP-captured mp4 broken In-Reply-To: <7942F389-4D79-4863-91A9-07FA3C395B09@live555.com> References: <7942F389-4D79-4863-91A9-07FA3C395B09@live555.com> Message-ID: Ross wrote: > Michi wrote: >> Am I correct to think that openRTSP should transcode the raw streams correctly using the -4 option? > > In principle, yes (except that our code doesn't do any "transcoding"; it just records already-encoded data). ?However, this is difficult to do well, because the ".mp4" file format is?ill-suited for?what we are trying to do here: Record a file that properly represents?incoming audio and video frames that are time-stamped. ?But undoubtedly this is one part of our code that could be improved. The result should be one file containing video and audio. If mp4 is an ill-suited format, what else would you recommend? Other file format or different workflow? Better to record the video- and audio-session separately and merge afterwards? Michi From marcin at speed666.info Thu Apr 11 04:05:58 2013 From: marcin at speed666.info (Marcin) Date: Thu, 11 Apr 2013 13:05:58 +0200 Subject: [Live-devel] openRTSP-captured mp4 broken In-Reply-To: References: <7942F389-4D79-4863-91A9-07FA3C395B09@live555.com> Message-ID: <51669916.60100@speed666.info> Hello, I had to do almost the same goal as You - record incomming AV stream (h264/aac) to MP4 files. What i did was that live555 only dumped streams into separate files and then i used MP4Box to merge them into working mp4 file. Greetings, Marcin Michael.Scholz at dlr.de pisze: > Ross wrote: > >> Michi wrote: >> >>> Am I correct to think that openRTSP should transcode the raw streams correctly using the -4 option? >>> >> In principle, yes (except that our code doesn't do any "transcoding"; it just records already-encoded data). However, this is difficult to do well, because the ".mp4" file format is ill-suited for what we are trying to do here: Record a file that properly represents incoming audio and video frames that are time-stamped. But undoubtedly this is one part of our code that could be improved. >> > > The result should be one file containing video and audio. > If mp4 is an ill-suited format, what else would you recommend? Other file format or different workflow? Better to record the video- and audio-session separately and merge afterwards? > > Michi > > _______________________________________________ > 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 Serge.Grondin at miranda.com Thu Apr 11 09:20:51 2013 From: Serge.Grondin at miranda.com (Serge.Grondin at miranda.com) Date: Thu, 11 Apr 2013 12:20:51 -0400 Subject: [Live-devel] RTP over RTSP broken with VLC and latest lib. Message-ID: Hi, I don't if this problem was reported before, I just find out yesterday when doing some testing with April 1st version. Streaming over TCP is now broken because of a recent change in the lib, I debugged it and this is the faulty line file OnDemandSeverMediaSubsession.cpp (line 463) if (fRTCPInstance != NULL) { // Hack: Send an initial RTCP "SR" packet, before the initial RTP packet, so that receivers will (likely) be able to // get RTCP-synchronized presentation times immediately: fRTCPInstance->sendReport(); } In TCP mode it is breaking the PLAY server answer to the client, here is the Wireshark grab of the RTSP communication: PLAY rtsp://10.6.4.140:5554/test/ RTSP/1.0 CSeq: 5 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Session: 89934BBE Range: npt=0.000- $..8....N.....^..5.J...m............N.....ca-rd-sgrondin....RTSP/1.0 200 OK <-------------------- PROBLEM --------------- CSeq: 5 Date: Thu, Apr 11 2013 16:09:08 GMT Range: npt=0.000- Session: 89934BBE RTP-Info: url=rtsp://10.6.4.140:5554/test/track1;seq=18959;rtptime=3703760758 You see that a SR packet was inserted before the server answer, this will disconnect any clients waiting the OK from the server. Got the problem with VLC and my own application. Suggested fix: if (dests->isTCP == False) { if (fRTCPInstance != NULL) { // Hack: Send an initial RTCP "SR" packet, before the initial RTP packet, so that receivers will (likely) be able to // get RTCP-synchronized presentation times immediately: fRTCPInstance->sendReport(); } } Thanks again for the great software library! Serge DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Legault at nuvation.com Thu Apr 11 08:30:12 2013 From: Richard.Legault at nuvation.com (Richard Legault) Date: Thu, 11 Apr 2013 08:30:12 -0700 Subject: [Live-devel] Need help creating a H264 stream from a video encoder source. Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE106606CBC@mailguy3.skynet.nuvation.com> Hi, Problem: I see the NALS being sent up but to the framer from the Video Source but the RTSP is not sending them out. Any ideas where I have gone wrong? Any suggestions would be greatly appreciated. >From the output from Wireshark. I think the problem may be the SDP record. I see the request and response but then VLC immediately tears down the connection after receiving the Source description. And if so how do I handle that? Here is what I have done to get this far: I am using the testOnDemandRTSPServer.cpp as my template I added the following to the main function. // Create VENC stream source { char const* streamName = "vencVideoTest"; char const* inputFileName = "/data/out/VID_CH00.h264"; // NOT USED it is here for information only ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); sms->addSubsession(H264VideoVencMediaSubsession ::createNew(*env,vencConfigSettings.chanId, reuseFirstSource)); rtspServer->addServerMediaSession(sms); announceStream(rtspServer, sms, streamName, inputFileName); } I've created the H264VideoVencMediaSubsession to inherit from the OnDemandServerMediaSubssession H264VideoVencMediaSubsession : OnDemandServerMediaSubsession The H264VideoVencMediaSubsession::createNewStreamSource returns a H264VideoStreamDiscreteFramer FramedSource* H264VideoVencMediaSubsession::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 500; // kbps, estimate fprintf(stderr,"%s:%d %s\n",__FILE__,__LINE__,__FUNCTION__); fflush(stderr); // Create the video source: VencSource* vencSource = VencSource::createNew(envir(), fChanId); if (vencSource == NULL) return NULL; vencSource->signalVencEventStartCB(); // need to register video encoder call back within scheduler thread // Create a framer for the Video Elementary Stream: return H264VideoStreamDiscreteFramer::createNew(envir(), vencSource); } The Video encoder hands VencSource VCL frames that may contain multiple NALs so the deliverFrame strips off the start NAL frame codes finds the end of the NAL unit and delivers one NAL unit per frame delivery. I see these NALS being sent up but the RTSP is not sending them out. Any ideas where I have gone wrong? Any suggestions would be greatly appreciated. >From the output from Wireshark. I think the problem may be the SDP record. I see the request and response but then VLC immediately tears down the connection after receiving the Source description. And if so how do I handle that? Thanks Richard Legault Lead Design Engineer Nuvation Research Waterloo On Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 168146 bytes Desc: image001.png URL: From finlayson at live555.com Thu Apr 11 11:33:13 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Apr 2013 11:33:13 -0700 Subject: [Live-devel] RTP over RTSP broken with VLC and latest lib. In-Reply-To: References: Message-ID: <1D62736E-6B2C-4F8B-9638-31323FBBB062@live555.com> > I don't if this problem was reported before, I just find out yesterday when doing some testing with April 1st version. Streaming over TCP is now broken because of a recent change in the lib > No, the library is not broken. The problem is here: > User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) > The RTSP *client* (in this case, VLC) is using an out-of-date version of our code. If you upgrade it to a recent, it should work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 11 12:01:13 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Apr 2013 12:01:13 -0700 Subject: [Live-devel] Need help creating a H264 stream from a video encoder source. In-Reply-To: <274F7B50569A1B4C9D7BCAB17A9C7BE106606CBC@mailguy3.skynet.nuvation.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE106606CBC@mailguy3.skynet.nuvation.com> Message-ID: <51CEA098-A3F1-4024-B47C-1E5C55CC4B06@live555.com> Initially, when debugging your server, you should use "testRTSPClient" - rather than VLC - as your RTSP client. ("testRTSPClient" will tell you a lot more about what's going on.) Please post the output from running "testRTSPClient" on your stream. > The H264VideoVencMediaSubsession::createNewStreamSource returns a H264VideoStreamDiscreteFramer Please also post the code for your implementation of the "createNewRTPSink()" virtual function. If possible (if you know, in advance, the SPS/PPS NAL units, or equivalently the 'sprop-parameter-sets" string, for your stream), you should use one of the forms of "H264VideoRTPSink::createNew()" that takes this information as a parameter. > The Video encoder hands VencSource VCL frames that may contain multiple NALs so the deliverFrame strips off the start NAL frame codes finds the end of the NAL unit and delivers one NAL unit per frame delivery. Good. That's the right thing to be doing. Make sure that you're setting "fFrameSize" correctly (taking into account that you're not delivering the 4-byte 'start code'), and, of course, don't forget to call "FramedSource::afterGetting(this);" to complete the delivery of each NAL unit. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeremiah.Morrill at econnect.tv Thu Apr 11 17:18:24 2013 From: Jeremiah.Morrill at econnect.tv (Jeremiah Morrill) Date: Fri, 12 Apr 2013 00:18:24 +0000 Subject: [Live-devel] BasicUsageEnvironment and liveMediaPriv!=NULL with TCP streaming Message-ID: <80C795F72B3CB241A9256DABF0A04EC53BB00B10@CH1PRD0710MB391.namprd07.prod.outlook.com> Hello, I'm running the latest version ( live.2013.04.08.tar.gz ) on Windows 7, for both rtsp client and server. I believe I have read all the old archives relating to basicUsageEnvironment->reclaim() and that basicUsageEnvironment->liveMediaPriv will be null if you close all your mediums. I am finding that is indeed the case if you use UDP with the RTSPClient and liveMediaPriv is null after I shut everything down (Medium:close). If I set RTSPClient to use TCP streaming, liveMediaPriv doesn't ever seem to be null. This is very reproducible within my code, but I was wondering if anyone else can reproduce this behavior, or have any hints on some extra step in clean-up I may be missing. Thanks! -Jer -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 11 18:01:00 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Apr 2013 18:01:00 -0700 Subject: [Live-devel] BasicUsageEnvironment and liveMediaPriv!=NULL with TCP streaming In-Reply-To: <80C795F72B3CB241A9256DABF0A04EC53BB00B10@CH1PRD0710MB391.namprd07.prod.outlook.com> References: <80C795F72B3CB241A9256DABF0A04EC53BB00B10@CH1PRD0710MB391.namprd07.prod.outlook.com> Message-ID: > I?m running the latest version ( live.2013.04.08.tar.gz ) on Windows 7, for both rtsp client and server. I believe I have read all the old archives relating to basicUsageEnvironment->reclaim() and that basicUsageEnvironment->liveMediaPriv will be null if you close all your mediums. > > I am finding that is indeed the case if you use UDP with the RTSPClient and liveMediaPriv is null after I shut everything down (Medium:close). > > If I set RTSPClient to use TCP streaming, liveMediaPriv doesn?t ever seem to be null. This is very reproducible within my code, but I was wondering if anyone else can reproduce this behavior, or have any hints on some extra step in clean-up I may be missing. Unfortunately I tried this just now with the "testRTSPClient" demo application (after modifying it to request RTP-over-TCP streaming, set the 'watch variable' and exit the event loop, and then call "env->reclaim()"), and wasn't able to reproduce this. Sorry. (I assume that you have a good reason for not running your client within its own process, and just calling "exit(0)" at the end. Many people *do* have a good reason for not doing this, but a lot of people these days don't seem to understand processes and "exit()", so I have to ask...) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nambirajan.manickam at i-velozity.com Fri Apr 12 02:19:35 2013 From: nambirajan.manickam at i-velozity.com (Nambirajan) Date: Fri, 12 Apr 2013 14:49:35 +0530 Subject: [Live-devel] Support required for Live555 Media Server Message-ID: <002701ce375e$de7e5d80$9b7b1880$@manickam@i-velozity.com> Hi, This is Nambirajan from I-Velozity India Private Limited, We are testing the Live555 Media Server for one of our application. While doing so we are facing the following problems and queries. Can you please help in this regard to solve the issue? 1. We have installed the Live555 Media Server on Red Hat Linux version 6.2 system. The Processor is Intel Pentium Dual core running at 2.6 GHz with 2GB DDR2 RAM We run multiple instances of OpenRTSP client program / VLC player application on 34 client systems and used the RTSP Server to stream to 34 clients. In this scenario The CPU utilization of our Live555 RTSP Server has reached approximately 92% for streaming. Beyond this, the RTSP stream in the first client system starts to freeze and play Is it true that each instance of streaming will take this much CPU resources? Is it common for all types of machines irrespective of its configuration? 2. Is it possible to run two instances of Live555 Media Server application in the same Server simultaneously? 3. Is it possible for us to make the Live555 Media Server to assign the IP address of our wish. Example: There are two NIC ( Network Interface Card )in the system, onboard as well as PCI card based NIC. Is it possible to make the Live555 Media server to take the PCI based NIC IP Address instead of onboard NIC IP Address.? We want assign Onboard NIC IP Address to one Live555 Media Server instance and PCI NIC card IP Address to another instance of Live555 Media Server instance running simultaneously on the same system. Thanks and regards, M. Nambirajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Serge.Grondin at miranda.com Fri Apr 12 07:07:19 2013 From: Serge.Grondin at miranda.com (Serge.Grondin at miranda.com) Date: Fri, 12 Apr 2013 10:07:19 -0400 Subject: [Live-devel] RTP over RTSP broken with VLC and latest lib. In-Reply-To: <1D62736E-6B2C-4F8B-9638-31323FBBB062@live555.com> References: <1D62736E-6B2C-4F8B-9638-31323FBBB062@live555.com> Message-ID: OK, I understand but would it be possible to have at least a define to remove that line of code (the SR packet hack) for those who don't want to brake the compatibility with older versions? This code as been working for years with VLC, that now means that my server will only be compatible with VLC 2.0.6 from now on. Regard, Serge From: Ross Finlayson To: LIVE555 Streaming Media - development & use , Date: 2013-04-11 14:51 Subject: Re: [Live-devel] RTP over RTSP broken with VLC and latest lib. Sent by: live-devel-bounces at ns.live555.com I don't if this problem was reported before, I just find out yesterday when doing some testing with April 1st version. Streaming over TCP is now broken because of a recent change in the lib No, the library is not broken. The problem is here: User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) The RTSP *client* (in this case, VLC) is using an out-of-date version of our code. If you upgrade it to a recent, it should work. 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 DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From finlayson at live555.com Fri Apr 12 07:13:42 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Apr 2013 07:13:42 -0700 Subject: [Live-devel] RTP over RTSP broken with VLC and latest lib. In-Reply-To: References: <1D62736E-6B2C-4F8B-9638-31323FBBB062@live555.com> Message-ID: No. There are several bugs (not just this one) in old versions of the code. Therefore, we do not support them. Client applications (including VLC) should upgrade to use a recent version of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 12 07:46:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Apr 2013 07:46:15 -0700 Subject: [Live-devel] Support required for Live555 Media Server In-Reply-To: <002701ce375e$de7e5d80$9b7b1880$@manickam@i-velozity.com> References: <002701ce375e$de7e5d80$9b7b1880$@manickam@i-velozity.com> Message-ID: > 1. We have installed the Live555 Media Server on Red Hat Linux version 6.2 system. The Processor is Intel Pentium Dual core running at 2.6 GHz with 2GB DDR2 RAM > We run multiple instances of OpenRTSP client program / VLC player application on 34 client systems and used the RTSP Server to stream to 34 clients. In this scenario > The CPU utilization of our Live555 RTSP Server has reached approximately 92% for streaming. Beyond this, the RTSP stream in the first client system starts to freeze and play > Is it true that each instance of streaming will take this much CPU resources? I suspect that you're hitting (or running close to hitting) an operating system limit for the number of possible open sockets (see also ). You may wish to increase this limit, if you can. > 2. Is it possible to run two instances of Live555 Media Server application in the same Server simultaneously? Yes, by having each instance use a different RTSP port number. > 3. Is it possible for us to make the Live555 Media Server to assign the IP address of our wish. Example: There are two NIC ( Network Interface Card )in the system, > onboard as well as PCI card based NIC. Is it possible to make the Live555 Media server to take the PCI based NIC IP Address instead of onboard NIC IP Address.? Yes. The easiest way to ensure that one particular interface is chosen is to make that interface the one for which multicast routing is enabled - i.e., the interface that has a route for 224.0.0.0/4 Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tboonefisher at clear.net Fri Apr 12 13:05:30 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Fri, 12 Apr 2013 15:05:30 -0500 Subject: [Live-devel] How To Decode This Camera Stream Message-ID: <20B35AE92B774C8289CB3D32C2AD9BAB@tbxpnotebook> FINALLY got it working!! Typical rookie mistakes including but not limited to trying to use a 32bit FFDShow filter in a 64bit app!! DUH! When I substituted the FFDShow MP4 decoder for the MS DTV-DVD Video Decoder, everything works well. Now just need to clean up the code. Actually works better and is faster than VLC for the same rtsp URL. Thanks again for a very nice library and your tolerance of a rookie... Tom Fisher MD EE -----Original Message----- From: tboonefisher at clear.net Sent: Friday, April 12, 2013 9:58 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] How To Decode This Camera Stream As I previously posted, I am trying to write a Direct Show source filter using code adapted from the example testRTSPClient to display the video stream from the following Foscam camera. As you pointed out, Foscam is using an outdated version of the Live555 server that is not sending appropriate start codes. Despite this, when I pass the NAL units directly from my source filter to a connected Microsoft DTV-DVD Video Decoder, I get "good" video for the first few seconds and then the frames start getting "mixed up" for lack of a better description. The video is displayed correctly albeit with a great amount of latency when using VLC. I will be happy to post the appropriate segments of my code here if anyone can help me with it. It will be greatly appreciated. The following link is a live demo stream from the same model camera at Foscam so anyone interested can take a look at what I'm dealing with: rtsp://user:user at 218.17.160.187:8082/videoMain Tom Fisher From nambirajan.manickam at i-velozity.com Sat Apr 13 03:09:12 2013 From: nambirajan.manickam at i-velozity.com (Nambirajan) Date: Sat, 13 Apr 2013 15:39:12 +0530 Subject: [Live-devel] Support required for Live555 Media Server In-Reply-To: References: <002701ce375e$de7e5d80$9b7b1880$@manickam@i-velozity.com> Message-ID: <000001ce382e$f7edc910$e7c95b30$@manickam@i-velozity.com> Dear Mr. Ross Finlayson, Thanks for your reply and suggestion. 1. We want to run two instances of Live555 Media Server in a system simultaneously with two different IP addresses. Example one with 192.168.1.2 and other with 10.0.0.2. Is it possible and how can we achieve this? 2. Can you please tell us whether running Live555 Media Sever on different configuration systems will affect the number of RTSP streams it can stream to multiple clients. Example like 50 streams max on a Pentium Dual Core system and 100 streams max in a Pentium Core 2 Duo system 3. When running each instance in a client, the CPU utilization seems to go up as follows. Approximately on a Pentium Core 2 Duo system serving 60 clients it takes 95%. CPU utilization ( Live555 Media Server ) It takes roughly 1.5% CPU utilization time per client. We are using OpenRTSP as client running on different system. Is Live555 Media Server is CPU intensive application? Thanks and regards, M. Nambirajan From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, April 12, 2013 8:16 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Support required for Live555 Media Server 1. We have installed the Live555 Media Server on Red Hat Linux version 6.2 system. The Processor is Intel Pentium Dual core running at 2.6 GHz with 2GB DDR2 RAM We run multiple instances of OpenRTSP client program / VLC player application on 34 client systems and used the RTSP Server to stream to 34 clients. In this scenario The CPU utilization of our Live555 RTSP Server has reached approximately 92% for streaming. Beyond this, the RTSP stream in the first client system starts to freeze and play Is it true that each instance of streaming will take this much CPU resources? I suspect that you're hitting (or running close to hitting) an operating system limit for the number of possible open sockets (see also ). You may wish to increase this limit, if you can. 2. Is it possible to run two instances of Live555 Media Server application in the same Server simultaneously? Yes, by having each instance use a different RTSP port number. 3. Is it possible for us to make the Live555 Media Server to assign the IP address of our wish. Example: There are two NIC ( Network Interface Card )in the system, onboard as well as PCI card based NIC. Is it possible to make the Live555 Media server to take the PCI based NIC IP Address instead of onboard NIC IP Address.? Yes. The easiest way to ensure that one particular interface is chosen is to make that interface the one for which multicast routing is enabled - i.e., the interface that has a route for 224.0.0.0/4 Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Apr 13 07:16:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 13 Apr 2013 07:16:35 -0700 Subject: [Live-devel] Support required for Live555 Media Server In-Reply-To: <000001ce382e$f7edc910$e7c95b30$@manickam@i-velozity.com> References: <002701ce375e$de7e5d80$9b7b1880$@manickam@i-velozity.com> <000001ce382e$f7edc910$e7c95b30$@manickam@i-velozity.com> Message-ID: <18FA3D2B-1AB8-42A4-B8BE-9F62A82B5268@live555.com> > 1. We want to run two instances of Live555 Media Server in a system simultaneously with two different IP addresses. Example one with 192.168.1.2 and other with 10.0.0.2. > Is it possible and how can we achieve this? You *might* be able to do this by setting "SendingInterfaceAddr" and "ReceivingInterfaceAddr" in the instance of the server that you want to use the non-default (i.e., non-multicast-enabled) IP address. This does not work reliably on all OS's, however. > 2. Can you please tell us whether running Live555 Media Sever on different configuration systems will affect the number of RTSP streams it can stream to multiple clients. I've already answered this. For the last time: http://www.live555.com/liveMedia/faq.html#scalability > Is Live555 Media Server is CPU intensive application? No. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Sat Apr 13 10:49:23 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Sat, 13 Apr 2013 17:49:23 +0000 Subject: [Live-devel] saving or rebroadcasting incoming RTP A/V stream as MPEG-2 transport stream Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010E9B09@postal.sonicfoundry.net> I saw various source files (e.g. MPEG2TransportStreamMultiplexor.cpp) muxing into MPEG-2 TS. Is there a way a save and/or rebroadcast incoming RTP streams as MPEG-2 TS with the given code. Thanks Markus. From finlayson at live555.com Sat Apr 13 12:08:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 13 Apr 2013 12:08:15 -0700 Subject: [Live-devel] saving or rebroadcasting incoming RTP A/V stream as MPEG-2 transport stream In-Reply-To: <1ED2F9A76678E0428E90FB2B6F93672D010E9B09@postal.sonicfoundry.net> References: <1ED2F9A76678E0428E90FB2B6F93672D010E9B09@postal.sonicfoundry.net> Message-ID: <67E0D8BF-96C0-4D80-8A95-494370C01D27@live555.com> > I saw various source files (e.g. MPEG2TransportStreamMultiplexor.cpp) muxing into MPEG-2 TS. > Is there a way a save and/or rebroadcast incoming RTP streams as MPEG-2 TS with the given code. Yes, provided, of course, that the codec(s) used by the incoming RTP stream(s) are ones that can be carried within MPEG Transport Streams. You can do this by creating a "MPEG2TransportStreamFromESSource" object. Then, on this object, call "addNewVideoSource()" and/or "addNewAudioSource()", from the corresponding "MediaSubsession::readSource()". You can then feed the "MPEG2TransportStreamFromESSource" object into a "FileSink". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tboonefisher at clear.net Sat Apr 13 12:07:05 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Sat, 13 Apr 2013 14:07:05 -0500 Subject: [Live-devel] Support required for Live555 Media Server In-Reply-To: <18FA3D2B-1AB8-42A4-B8BE-9F62A82B5268@live555.com> References: <002701ce375e$de7e5d80$9b7b1880$@manickam@i-velozity.com> <000001ce382e$f7edc910$e7c95b30$@manickam@i-velozity.com> <18FA3D2B-1AB8-42A4-B8BE-9F62A82B5268@live555.com> Message-ID: What is the best *free* DirectShow H.264 decoder filter? TF From: Ross Finlayson Sent: Saturday, April 13, 2013 9:16 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Support required for Live555 Media Server 1. We want to run two instances of Live555 Media Server in a system simultaneously with two different IP addresses. Example one with 192.168.1.2 and other with 10.0.0.2. Is it possible and how can we achieve this? You *might* be able to do this by setting "SendingInterfaceAddr" and "ReceivingInterfaceAddr" in the instance of the server that you want to use the non-default (i.e., non-multicast-enabled) IP address. This does not work reliably on all OS's, however. 2. Can you please tell us whether running Live555 Media Sever on different configuration systems will affect the number of RTSP streams it can stream to multiple clients. I've already answered this. For the last time: http://www.live555.com/liveMedia/faq.html#scalability Is Live555 Media Server is CPU intensive application? No. 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 Michael.Scholz at dlr.de Tue Apr 16 04:16:09 2013 From: Michael.Scholz at dlr.de (Michael.Scholz at dlr.de) Date: Tue, 16 Apr 2013 11:16:09 +0000 Subject: [Live-devel] openRTSP-captured mp4 broken In-Reply-To: <51669916.60100@speed666.info> References: <7942F389-4D79-4863-91A9-07FA3C395B09@live555.com> <51669916.60100@speed666.info> Message-ID: Ceszcz! Marcin wrote: Hello, I had to do almost the same goal as You - record incomming AV stream (h264/aac) to MP4 files. What i did was that live555 only dumped streams into separate files and then i used MP4Box to merge them into working mp4 file. Thanks for this hint! I am not able to mux the video with the audio because MP4Box complains about "Audio isn't MPEG-2/4 AAC with ADTS, Error importing audio-MPEG4-GENERIC-2.aac: BitStream Not Compliant". Do I have to process the AAC separately in advance? Or use different file ending for correct recognition? Ciaoi, Michi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Legault at nuvation.com Tue Apr 16 06:40:05 2013 From: Richard.Legault at nuvation.com (Richard Legault) Date: Tue, 16 Apr 2013 06:40:05 -0700 Subject: [Live-devel] Need help creating a H264 stream from a video encoder source Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE1066073FF@mailguy3.skynet.nuvation.com> >Initially, when debugging your server, you should use "testRTSPClient" - rather than VLC - as your RTSP client. ("testRTSPClient" will tell you a lot more about what's going on.) Please post the output from running "testRTSPClient" on your stream. user at ubuntu:~/live555/testProgs$ ./testRTSPClient rtsp://10.0.0.23:8554/vencVideoTest Opening connection to 10.0.0.23, port 8554... ...remote connection opened Sending request: DESCRIBE rtsp://10.0.0.23:8554/vencVideoTest RTSP/1.0 CSeq: 2 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2012.11.22) Accept: application/sdp Received 694 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Sat, Apr 13 2013 05:45:20 GMT Content-Base: rtsp://10.0.0.23:8554/vencVideoTest/ Content-Type: application/sdp Content-Length: 525 v=0 o=- 1365831836462126 1 IN IP4 10.0.0.23 s=Session streamed by "testOnDemandRTSPServer" i=vencVideoTest t=0 0 a=tool:LIVE555 Streaming Media v2013.03.07 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer" a=x-qt-text-inf:vencVideoTest m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=J2QAH6 wXKgPARfuEAAAPoAADqYOAAAHoSAAB6Egve6yg,KN4Briw= a=control:track1 [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Got a SDP description: v=0 o=- 1365831836462126 1 IN IP4 10.0.0.23 s=Session streamed by "testOnDemandRTSPServer" i=vencVideoTest t=0 0 a=tool:LIVE555 Streaming Media v2013.03.07 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer" a=x-qt-text-inf:vencVideoTest m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=J2QAH6 wXKgPARfuEAAAPoAADqYOAAAHoSAAB6Egve6yg,KN4Briw= a=control:track1 [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Initiated the "video/H264" subsession (client ports 56046-56047) Sending request: SETUP rtsp://10.0.0.23:8554/vencVideoTest/track1 RTSP/1.0 CSeq: 3 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2012.11.22) Transport: RTP/AVP;unicast;client_port=56046-56047 Received 197 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Sat, Apr 13 2013 05:45:20 GMT Transport: RTP/AVP;unicast;destination=10.0.0.51;source=10.0.0.23;client_port=56046 -56047;server_port=6970-6971 Session: 69DD5EA2 [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Set up the "video/H264" subsession (client ports 56046-56047) [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Created a data sink for the "video/H264" subsession Sending request: PLAY rtsp://10.0.0.23:8554/vencVideoTest/ RTSP/1.0 CSeq: 4 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2012.11.22) Session: 69DD5EA2 Range: npt=0.000- Received 189 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Sat, Apr 13 2013 05:45:20 GMT Range: npt=0.000- Session: 69DD5EA2 RTP-Info: url=rtsp://10.0.0.23:8554/vencVideoTest/track1;seq=61844;rtptime=1754283 99 [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Started playing session... ^C user at ubuntu:~/live555_75/testProgs$ ./testRTSPClient rtsp://10.0.0.23:8554/vencVideoTest Opening connection to 10.0.0.23, port 8554... ...remote connection opened Sending request: DESCRIBE rtsp://10.0.0.23:8554/vencVideoTest RTSP/1.0 CSeq: 2 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2012.11.22) Accept: application/sdp Received 694 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Sat, Apr 13 2013 06:01:41 GMT Content-Base: rtsp://10.0.0.23:8554/vencVideoTest/ Content-Type: application/sdp Content-Length: 525 v=0 o=- 1365832880485653 1 IN IP4 10.0.0.23 s=Session streamed by "testOnDemandRTSPServer" i=vencVideoTest t=0 0 a=tool:LIVE555 Streaming Media v2013.03.07 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer" a=x-qt-text-inf:vencVideoTest m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=J2QAH6 wXKgPARfuEAAAPoAADqYOAAAHoSAAB6Egve6yg,KN4Briw= a=control:track1 [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Got a SDP description: v=0 o=- 1365832880485653 1 IN IP4 10.0.0.23 s=Session streamed by "testOnDemandRTSPServer" i=vencVideoTest t=0 0 a=tool:LIVE555 Streaming Media v2013.03.07 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer" a=x-qt-text-inf:vencVideoTest m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=J2QAH6 wXKgPARfuEAAAPoAADqYOAAAHoSAAB6Egve6yg,KN4Briw= a=control:track1 [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Initiated the "video/H264" subsession (client ports 35094-35095) Sending request: SETUP rtsp://10.0.0.23:8554/vencVideoTest/track1 RTSP/1.0 CSeq: 3 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2012.11.22) Transport: RTP/AVP;unicast;client_port=35094-35095 Received 197 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Sat, Apr 13 2013 06:01:41 GMT Transport: RTP/AVP;unicast;destination=10.0.0.51;source=10.0.0.23;client_port=35094 -35095;server_port=6970-6971 Session: CE22D089 [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Set up the "video/H264" subsession (client ports 35094-35095) [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Created a data sink for the "video/H264" subsession Sending request: PLAY rtsp://10.0.0.23:8554/vencVideoTest/ RTSP/1.0 CSeq: 4 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2012.11.22) Session: CE22D089 Range: npt=0.000- Received 188 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Sat, Apr 13 2013 06:01:41 GMT Range: npt=0.000- Session: CE22D089 RTP-Info: url=rtsp://10.0.0.23:8554/vencVideoTest/track1;seq=195;rtptime=212943001 5 [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Started playing session... >> The H264VideoVencMediaSubsession::createNewStreamSource returns a >> H264VideoStreamDiscreteFramer >Please also post the code for your implementation of the "createNewRTPSink()" virtual function. If possible (if you know, in advance, the SPS/PPS NAL units, or equivalently the 'sprop-parameter-sets" string, for your stream), you should use one of the forms of "H264VideoRTPSink::createNew()" that takes this information as a parameter. RTPSink* H264VideoVencMediaSubsession ::createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* /*inputSource*/) { fprintf(stderr,"%s:%d %s\n",__FILE__,__LINE__,__FUNCTION__); return H264VideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); } >> The Video encoder hands VencSource VCL frames that may contain multiple NALs so the deliverFrame strips off the start NAL frame codes finds the end of the NAL unit and delivers one NAL unit per frame delivery. > Good. That's the right thing to be doing. Make sure that you're setting "fFrameSize" correctly (taking into account that you're not delivering the 4-byte 'start code'), and, of course, don't forget to call "FramedSource::afterGetting(this);" to complete the delivery of each NAL unit. Yes I set the fFrameSize correctly to the number of nal unit bytes (subtracting 4). Yes I call FramedSource::afterGetting(this) Thanks for your quick response. Richard Legault Lead Design Engineer Nuvation Research Waterloo On Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 16 11:56:33 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Apr 2013 11:56:33 -0700 Subject: [Live-devel] Need help creating a H264 stream from a video encoder source In-Reply-To: <274F7B50569A1B4C9D7BCAB17A9C7BE1066073FF@mailguy3.skynet.nuvation.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE1066073FF@mailguy3.skynet.nuvation.com> Message-ID: > >Initially, when debugging your server, you should use "testRTSPClient" - rather than VLC - as your RTSP client. ("testRTSPClient" will tell you a lot more about what's going on.) Please post the output from running "testRTSPClient" on your stream. > > user at ubuntu:~/live555/testProgs$ ./testRTSPClient rtsp://10.0.0.23:8554/vencVideoTest > > Opening connection to 10.0.0.23, port 8554... > > ...remote connection opened > [...] > [URL:"rtsp://10.0.0.23:8554/vencVideoTest/"]: Started playing session... > > ^C > I presume that you're -C'ing the application here because it doesn't report receiving any data. Is the client computer on the same LAN as the server? (Make sure that it's not behind a firewall that's blocking UDP packets.) But assuming that there's nothing that would stop UDP packets from reaching the client, then the server must not be transmitting them, for some reason. The only thing (as far as I can tell) that could be causing that to happen would be if there's something wrong with your H.264 NAL source, and it's not delivering proper H.264 NAL units to the downstream "H264VideoStreamDiscreteFramer". So I'd suggest checking - in "H264VideoStreamDiscreteFramer::afterGettingFrame1()" - that it's getting reasonable-looking data, and that "frameSize" is what it should be. But apart from that, I don't know what to suggest. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeremiah.Morrill at econnect.tv Tue Apr 16 13:47:37 2013 From: Jeremiah.Morrill at econnect.tv (Jeremiah Morrill) Date: Tue, 16 Apr 2013 20:47:37 +0000 Subject: [Live-devel] BasicUsageEnvironment and liveMediaPriv!=NULL with TCP streaming In-Reply-To: References: <80C795F72B3CB241A9256DABF0A04EC53BB00B10@CH1PRD0710MB391.namprd07.prod.outlook.com> Message-ID: <80C795F72B3CB241A9256DABF0A04EC53BB09283@CH1PRD0710MB391.namprd07.prod.outlook.com> Thank you so much for your quick reply. I'm always amazed on how quickly you get back to this list! OTOH, I apologize for how late it took me to get back to your response. I could not figure out why my liveMediaPriv was never null on TCP streams. Even tried directly on an IP camera's RTSP in case I was doing something screwy with the RTSP server...but with no luck. I ended up writing a hack on my cleanup code that you may scold me on =) auto tables = static_cast<_Tables*>(basicUsageEnvironment->liveMediaPriv); if(tables) { auto socketTable = static_cast(tables->socketTable); if(socketTable && socketTable->IsEmpty()) { delete socketTable; tables->socketTable = nullptr; tables->reclaimIfPossible(); } } basicUsageEnvironment->reclaim(); In my case, the socketTable->IsEmpty() is seems to be always true and everything seems to be deleted and free'd ok. I'm not sure if this hack gives any further clues into what I'm doing incorrect or not. Anyways, on your other point. Yes the OS is the best garbage collector out there =), but in this case, the RTSP client code is in a GUI on Windows and architecturally made sense to have it in the same process. Thanks again for all your great help. I've learned so much just subscribing to the list. -Jer -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 16 14:51:03 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Apr 2013 14:51:03 -0700 Subject: [Live-devel] BasicUsageEnvironment and liveMediaPriv!=NULL with TCP streaming In-Reply-To: <80C795F72B3CB241A9256DABF0A04EC53BB09283@CH1PRD0710MB391.namprd07.prod.outlook.com> References: <80C795F72B3CB241A9256DABF0A04EC53BB00B10@CH1PRD0710MB391.namprd07.prod.outlook.com> <80C795F72B3CB241A9256DABF0A04EC53BB09283@CH1PRD0710MB391.namprd07.prod.outlook.com> Message-ID: <54D01D0C-E1C8-4A02-8CFC-1B0931E90C96@live555.com> I've just installed a new version (2013.04.16) of the "LIVE555 Streaming Media" code that patches a 'loophole' (I'm reluctant to call it a 'bug' :-) that could have caused the socketTable to be non-NULL, but empty. If you use this new version, and you close all objects properly, your "liveMediaPriv" should always be NULL. (In any case, I'm not going to lose sleep about this. Any 'memory leak' here - even if it existed - would be so minor, it would likely be dwarfed by other memory leaks elsewhere in your process (i.e., your other runtime libraries, or your own application code).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeremiah.Morrill at econnect.tv Tue Apr 16 15:34:12 2013 From: Jeremiah.Morrill at econnect.tv (Jeremiah Morrill) Date: Tue, 16 Apr 2013 22:34:12 +0000 Subject: [Live-devel] BasicUsageEnvironment and liveMediaPriv!=NULL with TCP streaming In-Reply-To: <54D01D0C-E1C8-4A02-8CFC-1B0931E90C96@live555.com> References: <80C795F72B3CB241A9256DABF0A04EC53BB00B10@CH1PRD0710MB391.namprd07.prod.outlook.com> <80C795F72B3CB241A9256DABF0A04EC53BB09283@CH1PRD0710MB391.namprd07.prod.outlook.com> <54D01D0C-E1C8-4A02-8CFC-1B0931E90C96@live555.com> Message-ID: <80C795F72B3CB241A9256DABF0A04EC53BB0B376@CH1PRD0710MB391.namprd07.prod.outlook.com> Thanks so much! Just tried it out and works as you said! This will surely appease my pedantic overlords =) -Jer From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, April 16, 2013 2:51 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] BasicUsageEnvironment and liveMediaPriv!=NULL with TCP streaming I've just installed a new version (2013.04.16) of the "LIVE555 Streaming Media" code that patches a 'loophole' (I'm reluctant to call it a 'bug' :-) that could have caused the socketTable to be non-NULL, but empty. If you use this new version, and you close all objects properly, your "liveMediaPriv" should always be NULL. (In any case, I'm not going to lose sleep about this. Any 'memory leak' here - even if it existed - would be so minor, it would likely be dwarfed by other memory leaks elsewhere in your process (i.e., your other runtime libraries, or your own application code).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Wed Apr 17 14:54:47 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Wed, 17 Apr 2013 21:54:47 +0000 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010E9D58@postal.sonicfoundry.net> Ross, Thanks for your initial answer! I am still trying to save an incoming RTP AVC/AAC stream inside a MPEG-2 transport stream. I followed the flow of your testRTSPClient.cpp example which worked perfectly for my first application. I created a MPEG2TransportStreamFromESSource, FileSink and MediaSession. pRTSPClient->m_pMPEG2TransportStreamFromESSource = MPEG2TransportStreamFromESSource::createNew(env); pRTSPClient->m_pFileSink = FileSink::createNew(env,pRTSPClient->m_sOutputFilename.c_str()); scs.m_pMediaSession = MediaSession::createNew(env, sdpDescription); For each MediaSubsession I am always getting AVC/AAC - hence 5 & 4 as MPEG type for each sub session I do: if( strcmp(scs.m_pMediaSubsession->mediumName(),"video") == 0) { pRTSPClient->m_pMPEG2TransportStreamFromESSource->addNewVideoSource(scs.m_pMediaSubsession->readSource(),5); } if( strcmp(scs.m_pMediaSubsession->mediumName(),"audio") == 0) { pRTSPClient->m_pMPEG2TransportStreamFromESSource->addNewAudioSource(scs.m_pMediaSubsession->readSource(),4); } else { // error } Do I set scs.m_pMediaSubsession->sink? Do I call scs.m_pMediaSubsession->sink->startPlaying( *(scs.m_pMediaSubsession->readSource()), RecordingSubsessionAfterPlaying, scs.m_pMediaSubsession); How Do I feed a MPEG2TransportStreamFromESSource into the file sink? I only found pRTSPClient->m_pFileSink->startPlaying( *pRTSPClient->m_pMPEG2TransportStreamFromESSource, NULL, NULL); Thanks Markus From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Saturday, April 13, 2013 2:08 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] saving or rebroadcasting incoming RTP A/V stream as MPEG-2 transport stream I saw various source files (e.g. MPEG2TransportStreamMultiplexor.cpp) muxing into MPEG-2 TS. Is there a way a save and/or rebroadcast incoming RTP streams as MPEG-2 TS with the given code. Yes, provided, of course, that the codec(s) used by the incoming RTP stream(s) are ones that can be carried within MPEG Transport Streams. You can do this by creating a "MPEG2TransportStreamFromESSource" object. Then, on this object, call "addNewVideoSource()" and/or "addNewAudioSource()", from the corresponding "MediaSubsession::readSource()". You can then feed the "MPEG2TransportStreamFromESSource" object into a "FileSink". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Wed Apr 17 15:55:57 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Wed, 17 Apr 2013 22:55:57 +0000 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010E9D88@postal.sonicfoundry.net> One more thing - I end up with a stack overflow: SfLive555Client.dll!FileSink::afterGettingFrame(void * clientData, unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime, unsigned int __formal) Line 88 + 0x1f bytes C++ SfLive555Client.dll!FramedSource::afterGetting(FramedSource * source) Line 91 + 0x31 bytes C++ SfLive555Client.dll!MPEG2TransportStreamMultiplexor::doGetNextFrame() Line 83 + 0x9 bytes C++ SfLive555Client.dll!FramedSource::getNextFrame(unsigned char * to, unsigned int maxSize, void (void *, unsigned int, unsigned int, timeval, unsigned int)* afterGettingFunc, void * afterGettingClientData, void (void *)* onCloseFunc, void * onCloseClientData) Line 78 + 0xf bytes C++ SfLive555Client.dll!FileSink::continuePlaying() Line 80 C++ SfLive555Client.dll!FileSink::afterGettingFrame(unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime) Line 141 + 0xf bytes C++ SfLive555Client.dll!FileSink::afterGettingFrame(void * clientData, unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime, unsigned int __formal) Line 88 + 0x1f bytes C++ SfLive555Client.dll!FramedSource::afterGetting(FramedSource * source) Line 91 + 0x31 bytes C++ SfLive555Client.dll!MPEG2TransportStreamMultiplexor::doGetNextFrame() Line 83 + 0x9 bytes C++ SfLive555Client.dll!FramedSource::getNextFrame(unsigned char * to, unsigned int maxSize, void (void *, unsigned int, unsigned int, timeval, unsigned int)* afterGettingFunc, void * afterGettingClientData, void (void *)* onCloseFunc, void * onCloseClientData) Line 78 + 0xf bytes C++ SfLive555Client.dll!FileSink::continuePlaying() Line 80 C++ SfLive555Client.dll!FileSink::afterGettingFrame(unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime) Line 141 + 0xf bytes C++ SfLive555Client.dll!FileSink::afterGettingFrame(void * clientData, unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime, unsigned int __formal) Line 88 + 0x1f bytes C++ SfLive555Client.dll!FramedSource::afterGetting(FramedSource * source) Line 91 + 0x31 bytes C++ SfLive555Client.dll!MPEG2TransportStreamMultiplexor::doGetNextFrame() Line 83 + 0x9 bytes C++ SfLive555Client.dll!FramedSource::getNextFrame(unsigned char * to, unsigned int maxSize, void (void *, unsigned int, unsigned int, timeval, unsigned int)* afterGettingFunc, void * afterGettingClientData, void (void *)* onCloseFunc, void * onCloseClientData) Line 78 + 0xf bytes C++ SfLive555Client.dll!FileSink::continuePlaying() Line 80 C++ SfLive555Client.dll!FileSink::afterGettingFrame(unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime) Line 141 + 0xf bytes C++ SfLive555Client.dll!FileSink::afterGettingFrame(void * clientData, unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime, unsigned int __formal) Line 88 + 0x1f bytes C++ SfLive555Client.dll!FramedSource::afterGetting(FramedSource * source) Line 91 + 0x31 bytes C++ SfLive555Client.dll!MPEG2TransportStreamMultiplexor::doGetNextFrame() Line 83 + 0x9 bytes C++ SfLive555Client.dll!FramedSource::getNextFrame(unsigned char * to, unsigned int maxSize, void (void *, unsigned int, unsigned int, timeval, unsigned int)* afterGettingFunc, void * afterGettingClientData, void (void *)* onCloseFunc, void * onCloseClientData) Line 78 + 0xf bytes C++ SfLive555Client.dll!FileSink::continuePlaying() Line 80 C++ SfLive555Client.dll!FileSink::afterGettingFrame(unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime) Line 141 + 0xf bytes C++ SfLive555Client.dll!FileSink::afterGettingFrame(void * clientData, unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime, unsigned int __formal) Line 88 + 0x1f bytes C++ SfLive555Client.dll!FramedSource::afterGetting(FramedSource * source) Line 91 + 0x31 bytes C++ SfLive555Client.dll!MPEG2TransportStreamMultiplexor::doGetNextFrame() Line 83 + 0x9 bytes C++ SfLive555Client.dll!MPEG2TransportStreamMultiplexor::handleNewBuffer(unsigned char * buffer, unsigned int bufferSize, int mpegVersion, MPEG1or2Demux::SCR scr) Line 135 + 0xf bytes C++ SfLive555Client.dll!InputESSourceRecord::deliverBufferToClient() Line 222 C++ SfLive555Client.dll!MPEG2TransportStreamFromESSource::awaitNewBuffer(unsigned char * oldBuffer) Line 133 + 0x8 bytes C++ SfLive555Client.dll!InputESSourceRecord::afterGettingFrame1(unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime) Line 259 + 0x19 bytes C++ SfLive555Client.dll!InputESSourceRecord::afterGettingFrame(void * clientData, unsigned int frameSize, unsigned int numTruncatedBytes, timeval presentationTime, unsigned int __formal) Line 232 C++ SfLive555Client.dll!FramedSource::afterGetting(FramedSource * source) Line 91 + 0x31 bytes C++ SfLive555Client.dll!MultiFramedRTPSource::doGetNextFrame1() Line 198 + 0x9 bytes C++ SfLive555Client.dll!MultiFramedRTPSource::networkReadHandler1() Line 325 C++ SfLive555Client.dll!MultiFramedRTPSource::networkReadHandler(MultiFramedRTPSource * source, int __formal) Line 222 C++ SfLive555Client.dll!BasicTaskScheduler::SingleStep(unsigned int maxDelayTime) Line 163 + 0x1e bytes C++ SfLive555Client.dll!BasicTaskScheduler0::doEventLoop(char * watchVariable) Line 80 + 0x11 bytes C++ SfLive555Client.dll!RecordingClient::Run() Line 187 + 0x33 bytes C++ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Markus Schumann Sent: Wednesday, April 17, 2013 4:55 PM To: LIVE555 Streaming Media - development & use Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream Ross, Thanks for your initial answer! I am still trying to save an incoming RTP AVC/AAC stream inside a MPEG-2 transport stream. I followed the flow of your testRTSPClient.cpp example which worked perfectly for my first application. I created a MPEG2TransportStreamFromESSource, FileSink and MediaSession. pRTSPClient->m_pMPEG2TransportStreamFromESSource = MPEG2TransportStreamFromESSource::createNew(env); pRTSPClient->m_pFileSink = FileSink::createNew(env,pRTSPClient->m_sOutputFilename.c_str()); scs.m_pMediaSession = MediaSession::createNew(env, sdpDescription); For each MediaSubsession I am always getting AVC/AAC - hence 5 & 4 as MPEG type for each sub session I do: if( strcmp(scs.m_pMediaSubsession->mediumName(),"video") == 0) { pRTSPClient->m_pMPEG2TransportStreamFromESSource->addNewVideoSource(scs.m_pMediaSubsession->readSource(),5); } if( strcmp(scs.m_pMediaSubsession->mediumName(),"audio") == 0) { pRTSPClient->m_pMPEG2TransportStreamFromESSource->addNewAudioSource(scs.m_pMediaSubsession->readSource(),4); } else { // error } Do I set scs.m_pMediaSubsession->sink? Do I call scs.m_pMediaSubsession->sink->startPlaying( *(scs.m_pMediaSubsession->readSource()), RecordingSubsessionAfterPlaying, scs.m_pMediaSubsession); How Do I feed a MPEG2TransportStreamFromESSource into the file sink? I only found pRTSPClient->m_pFileSink->startPlaying( *pRTSPClient->m_pMPEG2TransportStreamFromESSource, NULL, NULL); Thanks Markus From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Saturday, April 13, 2013 2:08 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] saving or rebroadcasting incoming RTP A/V stream as MPEG-2 transport stream I saw various source files (e.g. MPEG2TransportStreamMultiplexor.cpp) muxing into MPEG-2 TS. Is there a way a save and/or rebroadcast incoming RTP streams as MPEG-2 TS with the given code. Yes, provided, of course, that the codec(s) used by the incoming RTP stream(s) are ones that can be carried within MPEG Transport Streams. You can do this by creating a "MPEG2TransportStreamFromESSource" object. Then, on this object, call "addNewVideoSource()" and/or "addNewAudioSource()", from the corresponding "MediaSubsession::readSource()". You can then feed the "MPEG2TransportStreamFromESSource" object into a "FileSink". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 17 23:59:31 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Apr 2013 23:59:31 -0700 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream In-Reply-To: <1ED2F9A76678E0428E90FB2B6F93672D010E9D58@postal.sonicfoundry.net> References: <1ED2F9A76678E0428E90FB2B6F93672D010E9D58@postal.sonicfoundry.net> Message-ID: <63C71BA1-22EC-457B-A98C-C99AF2CE09F5@live555.com> > Do I call [...]sink->startPlaying( Yes, of course. All LIVE555-based applications call "startPlaying()" on one or more 'sink' objects (subclasses of "MediaSink"). (For "testRTSPClient" and the "*Streamer" applications, this is done just before entering the event loop; for the RTSP server applications, this is done when handling an event within the event loop.) The big difference between "testRTSPClient" and your proposed application is that "testRTSPClient" creates several "DummySink" objects (one for each subsession), and calls "startPlaying()" on each one. Your application, on the other hand, will have just one 'sink' object - a "FileSink" - and you will call "startPlaying()" on it (just once!), with the "MPEG2TransportStreamFromESSource" object as source parameter. I suggest that your "continueAfterSETUP()" function call "addNewVideoSource()" or "addNewAudioSource()" (depending on the media type) on the "MPEG2TransportStreamFromESSource" object (using the corresponding subsession's "readSource()" as parameter). Then, for the *final* "continueAfterSETUP()" call only, call "startPlaying()" on the "FileSink" object. > How Do I feed a MPEG2TransportStreamFromESSource into the file sink? By calling "startPlaying()" on it (just once). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Thu Apr 18 09:30:24 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Thu, 18 Apr 2013 16:30:24 +0000 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream In-Reply-To: <63C71BA1-22EC-457B-A98C-C99AF2CE09F5@live555.com> References: <1ED2F9A76678E0428E90FB2B6F93672D010E9D58@postal.sonicfoundry.net> <63C71BA1-22EC-457B-A98C-C99AF2CE09F5@live555.com> Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010E9E2B@postal.sonicfoundry.net> Ross, Thanks for your answer. I tried it and I still get a stack overflow. 1) I had to modify the buffer size in liveMedia\MPEG2TransportStreamFromESSource.cpp(198) due to the following error message MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (99961). 41451 bytes of trailing data will be dropped! MPEG2TransportStreamFromESSource: input buffer too small; increase "MAX_INPUT_ES_FRAME_SIZE" in "MPEG2TransportStreamFromESSource" by at least 41451 bytes! 2) My overflowed stack look like this: FramedSource::afterGetting MPEG2TransportStreamMultiplexor::doGetNextFrame FramedSource::getNextFrame FileSink::continuePlaying FileSink::afterGettingFrame FileSink::afterGettingFrame FramedSource::afterGetting MPEG2TransportStreamMultiplexor::doGetNextFrame FramedSource::getNextFrame FileSink::continuePlaying FileSink::afterGettingFrame FileSink::afterGettingFrame FramedSource::afterGetting MPEG2TransportStreamMultiplexor::doGetNextFrame FramedSource::getNextFrame FileSink::continuePlaying FileSink::afterGettingFrame FileSink::afterGettingFrame FramedSource::afterGetting MPEG2TransportStreamMultiplexor::doGetNextFrame FramedSource::getNextFrame FileSink::continuePlaying FileSink::afterGettingFrame FileSink::afterGettingFrame FramedSource::afterGetting MPEG2TransportStreamMultiplexor::doGetNextFrame MPEG2TransportStreamMultiplexor::handleNewBuffer InputESSourceRecord::deliverBufferToClient MPEG2TransportStreamFromESSource::awaitNewBuffer InputESSourceRecord::afterGettingFrame1 InputESSourceRecord::afterGettingFrame FramedSource::afterGetting MultiFramedRTPSource::doGetNextFrame1 MultiFramedRTPSource::networkReadHandler1 MultiFramedRTPSource::networkReadHandler BasicTaskScheduler::SingleStep BasicTaskScheduler0::doEventLoop 3.) I saw the following comment in the code: liveMedia\MultiFramedRTPSource.cpp(198) // Call our own 'after getting' function, so that the downstream object can consume the data: if (fReorderingBuffer->isEmpty()) { // Common case optimization: There are no more queued incoming packets, so this code will not get // executed again without having first returned to the event loop. Call our 'after getting' function // directly, because there's no risk of a long chain of recursion (and thus stack overflow): afterGetting(this); I am definitely going through this code path. Do you have any advice? Thanks Markus. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, April 18, 2013 2:00 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream Do I call [...]sink->startPlaying( Yes, of course. All LIVE555-based applications call "startPlaying()" on one or more 'sink' objects (subclasses of "MediaSink"). (For "testRTSPClient" and the "*Streamer" applications, this is done just before entering the event loop; for the RTSP server applications, this is done when handling an event within the event loop.) The big difference between "testRTSPClient" and your proposed application is that "testRTSPClient" creates several "DummySink" objects (one for each subsession), and calls "startPlaying()" on each one. Your application, on the other hand, will have just one 'sink' object - a "FileSink" - and you will call "startPlaying()" on it (just once!), with the "MPEG2TransportStreamFromESSource" object as source parameter. I suggest that your "continueAfterSETUP()" function call "addNewVideoSource()" or "addNewAudioSource()" (depending on the media type) on the "MPEG2TransportStreamFromESSource" object (using the corresponding subsession's "readSource()" as parameter). Then, for the *final* "continueAfterSETUP()" call only, call "startPlaying()" on the "FileSink" object. How Do I feed a MPEG2TransportStreamFromESSource into the file sink? By calling "startPlaying()" on it (just once). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 18 11:51:57 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Apr 2013 11:51:57 -0700 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream In-Reply-To: <1ED2F9A76678E0428E90FB2B6F93672D010E9E2B@postal.sonicfoundry.net> References: <1ED2F9A76678E0428E90FB2B6F93672D010E9D58@postal.sonicfoundry.net> <63C71BA1-22EC-457B-A98C-C99AF2CE09F5@live555.com> <1ED2F9A76678E0428E90FB2B6F93672D010E9E2B@postal.sonicfoundry.net> Message-ID: <2E464E2B-2400-4677-868F-296E7F8157BA@live555.com> > I tried it and I still get a stack overflow. Grumble. What's happening here is not infinite recursion, but 'lots of' recursion - caused by the fact that some of your input frames (H.264, presumably) are so ridiculously large. Once again: A reminder to everyone who is encoding and streaming H.264 video: DO NOT encode your H.264 NAL units to be more than a few 10s of kBytes in size. But you can overcome this 'lots of' recursion stack overflow by changing line 83 of "MPEG2TransportStreamMultiplexor.cpp" from afterGetting(this); to envir().taskScheduler().scheduleDelayedTask(0, (TaskFunc*)FramedSource::afterGetting, this); Unfortunately, this will make the code (slightly) less efficient - but I'll make this change 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 finlayson at live555.com Thu Apr 18 12:06:56 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Apr 2013 12:06:56 -0700 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream In-Reply-To: <2E464E2B-2400-4677-868F-296E7F8157BA@live555.com> References: <1ED2F9A76678E0428E90FB2B6F93672D010E9D58@postal.sonicfoundry.net> <63C71BA1-22EC-457B-A98C-C99AF2CE09F5@live555.com> <1ED2F9A76678E0428E90FB2B6F93672D010E9E2B@postal.sonicfoundry.net> <2E464E2B-2400-4677-868F-296E7F8157BA@live555.com> Message-ID: <5194B1EB-B26F-4C30-A9D9-E34C6E9A5409@live555.com> > But you can overcome this 'lots of' recursion stack overflow by changing line 83 of "MPEG2TransportStreamMultiplexor.cpp" from > afterGetting(this); > to > envir().taskScheduler().scheduleDelayedTask(0, (TaskFunc*)FramedSource::afterGetting, this); Alternatively, to reduce the (slight) loss of inefficiency here, you could change this instead to: if ((fOutgoingPacketCounter%10) == 0) { envir().taskScheduler().scheduleDelayedTask(0, (TaskFunc*)FramedSource::afterGetting, this); } else { afterGetting(this); } Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Thu Apr 18 12:33:38 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Thu, 18 Apr 2013 19:33:38 +0000 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream In-Reply-To: <2E464E2B-2400-4677-868F-296E7F8157BA@live555.com> References: <1ED2F9A76678E0428E90FB2B6F93672D010E9D58@postal.sonicfoundry.net> <63C71BA1-22EC-457B-A98C-C99AF2CE09F5@live555.com> <1ED2F9A76678E0428E90FB2B6F93672D010E9E2B@postal.sonicfoundry.net> <2E464E2B-2400-4677-868F-296E7F8157BA@live555.com> Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010E9E77@postal.sonicfoundry.net> Ross, > Grumble. What's happening here is not infinite recursion, but 'lots of' recursion - caused by the fact that some of your input frames (H.264, presumably) are so ridiculously large. The frames are indent bigger - the camera is HD with a decent bitrate. I changed the stack size to 8 MB byte and your software finishes without stack overflow. You are working recursively though a larger buffer slicing a TS packet off one at a time resulting into 4k+ size call stack. > DO NOT encode your H.264 NAL units to be more than a few 10s of kBytes in size. Although this is good advice - I am not the one who is encoding - it's the hardware in the camera. Now I am getting a transport stream file but I can't play in WMP or open it in Sony Vegas. The TS file looks clean in my TS analyzer. Thanks Markus. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, April 18, 2013 1:52 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream I tried it and I still get a stack overflow. Grumble. What's happening here is not infinite recursion, but 'lots of' recursion - caused by the fact that some of your input frames (H.264, presumably) are so ridiculously large. Once again: A reminder to everyone who is encoding and streaming H.264 video: DO NOT encode your H.264 NAL units to be more than a few 10s of kBytes in size. But you can overcome this 'lots of' recursion stack overflow by changing line 83 of "MPEG2TransportStreamMultiplexor.cpp" from afterGetting(this); to envir().taskScheduler().scheduleDelayedTask(0, (TaskFunc*)FramedSource::afterGetting, this); Unfortunately, this will make the code (slightly) less efficient - but I'll make this change 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 finlayson at live555.com Thu Apr 18 12:54:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Apr 2013 12:54:09 -0700 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream In-Reply-To: <1ED2F9A76678E0428E90FB2B6F93672D010E9E77@postal.sonicfoundry.net> References: <1ED2F9A76678E0428E90FB2B6F93672D010E9D58@postal.sonicfoundry.net> <63C71BA1-22EC-457B-A98C-C99AF2CE09F5@live555.com> <1ED2F9A76678E0428E90FB2B6F93672D010E9E2B@postal.sonicfoundry.net> <2E464E2B-2400-4677-868F-296E7F8157BA@live555.com> <1ED2F9A76678E0428E90FB2B6F93672D010E9E77@postal.sonicfoundry.net> Message-ID: <824B1B3A-11BC-4043-AF1D-BF7723B3C38E@live555.com> > Now I am getting a transport stream file but I can?t play in WMP or open it in Sony Vegas. You should try VLC as well. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Thu Apr 18 13:54:26 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Thu, 18 Apr 2013 20:54:26 +0000 Subject: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010E9EFA@postal.sonicfoundry.net> VLC recognizes the correct length but no video and no audio. I am comparing the live555 saved file with a "clean" mpeg-2 TS file from my video camera. On the video camera each I-frame is "prefixed" with AUD, SPS, PPS and the other picture types (P and B) are prefixed with AUD and PPS. The PES structure is PES[AUD, SPS, PPS, I-frame, AUD, PPS, B-frame], PES[AUD,PPS,B-frame, AUD,PPS,P-frame] ... I wonder If I could hook somewhere into your TS generation and inject a few AUs, also discard everything up to the first I-frame and get control over the PES borders. Thanks Markus. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, April 18, 2013 2:54 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] saving incoming RTP A/V stream as MPEG-2 transport stream Now I am getting a transport stream file but I can't play in WMP or open it in Sony Vegas. You should try VLC as well. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 18 20:47:08 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Apr 2013 20:47:08 -0700 Subject: [Live-devel] A new survey: How would you improve the "LIVE555 Streaming Media" software Message-ID: <2525D9D3-1CC6-4308-8FA6-500ABE64DE4B@live555.com> The previous survey asked you how you were currently using the "LIVE555 Streaming Media" software. This new survey asks you what new feature(s) you would like to see in future releases of the software: https://www.surveymonkey.com/s/LIVE555_new_features Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Fri Apr 19 02:32:29 2013 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 19 Apr 2013 11:32:29 +0200 Subject: [Live-devel] test.m4e streaming not working anymore Message-ID: <5695787.QqFIRmnc5N@mnmsd> Hi, When I try to stream locally a m4e file like http://www.live555.com/liveMedia/public/m4e/para.m4e using testOnDemandRTSPServer, no data is transmitted. RTSP protocol exchange looks ok. A test.264 file works fine Best regards, S?bastien. From finlayson at live555.com Fri Apr 19 02:52:21 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Apr 2013 02:52:21 -0700 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <5695787.QqFIRmnc5N@mnmsd> References: <5695787.QqFIRmnc5N@mnmsd> Message-ID: <5A87FFF4-848A-4341-873F-6BE4CFC069EE@live555.com> > When I try to stream locally a m4e file like > http://www.live555.com/liveMedia/public/m4e/para.m4e using > testOnDemandRTSPServer, no data is transmitted. Data is definitely being transmitted - and is being received at the client end: ./openRTSP -n rtsp://4.79.217.242:8554/para.m4e Opening connection to 4.79.217.242, port 8554... ...local connection opened Sending request: OPTIONS rtsp://4.79.217.242:8554/para.m4e RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.04.16) Received 152 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Fri, Apr 19 2013 09:44:02 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Sending request: DESCRIBE rtsp://4.79.217.242:8554/para.m4e RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.04.16) Accept: application/sdp Received 665 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Fri, Apr 19 2013 09:44:02 GMT Content-Base: rtsp://4.79.217.242:8554/para.m4e/ Content-Type: application/sdp Content-Length: 498 v=0 o=- 1366364489655635 1 IN IP4 4.79.217.242 s=MPEG-4 Video, streamed by the LIVE555 Media Server i=para.m4e t=0 0 a=tool:LIVE555 Streaming Media v2013.04.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:MPEG-4 Video, streamed by the LIVE555 Media Server a=x-qt-text-inf:para.m4e m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=3;config=000001B003000001B509000001000000012000C8888007D05841214103 a=control:track1 Opened URL "rtsp://4.79.217.242:8554/para.m4e", returning a SDP description: v=0 o=- 1366364489655635 1 IN IP4 4.79.217.242 s=MPEG-4 Video, streamed by the LIVE555 Media Server i=para.m4e t=0 0 a=tool:LIVE555 Streaming Media v2013.04.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:MPEG-4 Video, streamed by the LIVE555 Media Server a=x-qt-text-inf:para.m4e m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=3;config=000001B003000001B509000001000000012000C8888007D05841214103 a=control:track1 Created receiver for "video/MP4V-ES" subsession (client ports 54170-54171) Sending request: SETUP rtsp://4.79.217.242:8554/para.m4e/track1 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.04.16) Transport: RTP/AVP;unicast;client_port=54170-54171 Received 203 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Fri, Apr 19 2013 09:44:02 GMT Transport: RTP/AVP;unicast;destination=4.79.217.242;source=4.79.217.242;client_port=54170-54171;server_port=6972-6973 Session: 2E0729EE Setup "video/MP4V-ES" subsession (client ports 54170-54171) Created output file: "video-MP4V-ES-1" Sending request: PLAY rtsp://4.79.217.242:8554/para.m4e/ RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2013.04.16) Session: 2E0729EE Range: npt=0.000- Received 188 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Fri, Apr 19 2013 09:44:02 GMT Range: npt=0.000- Session: 2E0729EE RTP-Info: url=rtsp://4.79.217.242:8554/para.m4e/track1;seq=46001;rtptime=2997460372 Started playing session Receiving streamed data (signal with "kill -HUP 81870" or "kill -USR1 81870" to terminate)... Data packets have begun arriving [1366364642373] HOWEVER, with VLC 2.0.6 as the client, the video doesn't render. Opening VLC's "Messages" log, I see several messages of the form: avcodec warning: cannot decode one frame ( bytes) As you noted, VLC can still play H.264 streams OK. So, the problem seems to be at the VLC end. Nothing related specifically to MPEG-4 video streaming has changed in the LIVE555 libraries recently. Has anything changed in VLC's "live555.cpp" interface code, or in the way that the rest of VLC handles MPEG-4 video?? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 19 02:57:10 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Apr 2013 02:57:10 -0700 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <5695787.QqFIRmnc5N@mnmsd> References: <5695787.QqFIRmnc5N@mnmsd> Message-ID: FYI, if you wish to test this further, I've left a server running, with the following streams available: rtsp://4.79.217.242:8554/para.m4e rtsp://4.79.217.242:8554/petrov.m4e rtsp://4.79.217.242:8554/slamtv60.264 The first two (being MPEG-4 video) don't play on VLC 2.0.6, but the last one (being a H.264 video) does. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Fri Apr 19 03:06:25 2013 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 19 Apr 2013 12:06:25 +0200 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: Message-ID: <5943325.PZYGv6ZW8l@mnmsd> > FYI, if you wish to test this further, I've left a server running, with the > following streams available Yes, your server sends data, I can see this. But on my computer, testOnDemandRTSPServer sends nothing for the m4e file. When I use openRTSP the output file is empty. But the h264 file works fine. From finlayson at live555.com Fri Apr 19 03:34:16 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Apr 2013 03:34:16 -0700 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <5943325.PZYGv6ZW8l@mnmsd> References: <5943325.PZYGv6ZW8l@mnmsd> Message-ID: <02688765-145E-4394-BA7E-02C512933E42@live555.com> >> FYI, if you wish to test this further, I've left a server running, with the >> following streams available > > Yes, your server sends data, I can see this. > But on my computer, testOnDemandRTSPServer sends nothing for the m4e file. That's odd. I can't reproduce this at all. Are you using a recent version of the LIVE555 code? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Fri Apr 19 08:29:47 2013 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 19 Apr 2013 17:29:47 +0200 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <02688765-145E-4394-BA7E-02C512933E42@live555.com> Message-ID: <2066319.orSyahOp3o@mnmsd> >Are you using a recent version of the LIVE555 code? Yes, latest From finlayson at live555.com Fri Apr 19 08:58:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Apr 2013 08:58:55 -0700 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <2066319.orSyahOp3o@mnmsd> References: <2066319.orSyahOp3o@mnmsd> Message-ID: <6D1BD17E-513E-4AB4-96EE-E6B9E1C0E422@live555.com> Are you running "testOnDemandRTSPServer" (or "live555MediaServer") and "openRTSP -n" on the same computer (not just on the same LAN)? What OS is this? I've tried this on both FreeBSD and Mac OS X, and can't reproduce the problem at all. For me, both "para.m4e" (as "test.m4e") and a H.264 file (as "test.264") are transmitted by the server, and received OK by "openRTSP -n". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Fri Apr 19 09:18:14 2013 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 19 Apr 2013 18:18:14 +0200 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <6D1BD17E-513E-4AB4-96EE-E6B9E1C0E422@live555.com> Message-ID: <1522190.CLghy8uVdU@mnmsd> Yes, I run them on the same computer. For mpeg4ESVideoTest, nothing happens after : Started playing session Receiving streamed data (signal with "kill -HUP 4451" or "kill -USR1 4451" to terminate)... For h264ESVideoTest I can see Data packets have begun arriving [1366388266944] From sebastien-devel at celeos.eu Fri Apr 19 09:26:31 2013 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 19 Apr 2013 18:26:31 +0200 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <6D1BD17E-513E-4AB4-96EE-E6B9E1C0E422@live555.com> Message-ID: <4180851.nOZMPf81SE@mnmsd> > What OS is this? I forgot to answer this, I am runing linux ubuntu. From finlayson at live555.com Fri Apr 19 12:39:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Apr 2013 12:39:36 -0700 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <4180851.nOZMPf81SE@mnmsd> References: <4180851.nOZMPf81SE@mnmsd> Message-ID: <7F042A63-DC7D-4986-9DEE-B2D805431980@live555.com> On Apr 19, 2013, at 9:26 AM, S?bastien Escudier wrote: >> What OS is this? > > I forgot to answer this, I am runing linux ubuntu. I don't have access to a Ubuntu machine, but I tried just now with Fedora Linux, and couldn't reproduce the problem either. Are you sure that your "para.m4e" file (and the "test.m4e" that you've linked to it) is not an empty file by mistake? It should be 10982809 bytes long, and running "md5" on it produces MD5 (para.m4e) = 28b7efe0dab87ee37dc9058e881f396d Apart from this, because neither I nor anyone else has been able to reproduce this, I don't know what to suggest. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Fri Apr 19 14:36:51 2013 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 19 Apr 2013 23:36:51 +0200 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <7F042A63-DC7D-4986-9DEE-B2D805431980@live555.com> Message-ID: <2757146.5IjW9JMr82@mnmsd> You are right my file was corrupted, now it works. Thank you and sorry for the noise. I'll have a look with VLC. S?bastien. From CERLANDS at arinc.com Fri Apr 19 14:57:59 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Fri, 19 Apr 2013 21:57:59 +0000 Subject: [Live-devel] Trick-play - Reverse Message-ID: Can someone confirm if reverse play works fine? Whenever I supply a negative scale value to the Play-function it always plays forward. The speed is correct, but I've never been able to play in reverse. It might be some RTSP fluke with the Cisco VSM server we're using, but wanted to verify if reverse works fine for others. Also, kind of related to trick-play... Is it possible to do frame-stepping in RTSP? /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 Fri Apr 19 15:43:29 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Apr 2013 15:43:29 -0700 Subject: [Live-devel] Trick-play - Reverse In-Reply-To: References: Message-ID: <1817E988-647B-4805-8814-3ED6A0788CED@live555.com> > Whenever I supply a negative scale value to the Play-function it always plays forward. The speed is correct, but I've never been able to play in reverse. Don't forget to also specify a non-zero 'start time', so that the server knows where to start reverse-play from. > > It might be some RTSP fluke with the Cisco VSM server we're using Yes, this appears to be a problem with your server, so I don't know why you are asking about it here. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 19 15:52:17 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Apr 2013 15:52:17 -0700 Subject: [Live-devel] Trick-play - Reverse In-Reply-To: <1817E988-647B-4805-8814-3ED6A0788CED@live555.com> References: <1817E988-647B-4805-8814-3ED6A0788CED@live555.com> Message-ID: <891D19E5-E283-4EF1-925E-744C3B312B2D@live555.com> >> Whenever I supply a negative scale value to the Play-function it always plays forward. The speed is correct, but I've never been able to play in reverse. > > Don't forget to also specify a non-zero 'start time', so that the server knows where to start reverse-play from. Or, alternatively, if you have already been playing the stream, specify your 'start time' as -1.0, so that the client will omit a "Range:" header. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Fri Apr 19 22:13:53 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Sat, 20 Apr 2013 05:13:53 +0000 Subject: [Live-devel] Trick-play - Reverse In-Reply-To: <1817E988-647B-4805-8814-3ED6A0788CED@live555.com> References: <1817E988-647B-4805-8814-3ED6A0788CED@live555.com> Message-ID: Whenever I supply a negative scale value to the Play-function it always plays forward. The speed is correct, but I've never been able to play in reverse. Don't forget to also specify a non-zero 'start time', so that the server knows where to start reverse-play from. Thanks, I do that. I should probably also have mentioned that the streams are all indexed by absolute time. absoluteStartPosition below can e.g. be "20130420T040645.774Z". -10 in the example gives the exact same result as if I use 10. rtspClient->sendPlayCommand(*scs.session, continueAfterPLAY, scs.absoluteStartPosition, "", -10.0); The main reason I didn't blame Cisco's VSM server right away is because reverse play works in Cisco's player that comes with the server (which however doesn't use RTSP). /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 Sat Apr 20 00:03:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 20 Apr 2013 00:03:15 -0700 Subject: [Live-devel] Trick-play - Reverse In-Reply-To: References: <1817E988-647B-4805-8814-3ED6A0788CED@live555.com> Message-ID: <06F1C5EE-6A0B-4580-A5A2-963E4277A339@live555.com> > The main reason I didn't blame Cisco's VSM server right away is because reverse play works in Cisco's player that comes with the server (which however doesn't use RTSP). If the client's "PLAY" request is valid - which it probably is - then if the server doesn't do what you requested, then the fault has to be the server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Sat Apr 20 08:51:50 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Sat, 20 Apr 2013 15:51:50 +0000 Subject: [Live-devel] Access violation during ReorderPacketBuffer::freepacket Message-ID: <615FD77639372542BF647F5EBAA2DBC225309264@IL-BOL-EXCH01.smartwire.com> I have been trying to solve this issue in my code since before I updated to the 2013.03.07 code. Inspection always shows the packet having a valid address but the guts of the packet are tagged with the heap code for destruction. It is ALWAYS immediately follows the error message : MultiFramedRTPSource error: Hit limit when reading incoming packet over TCP. Increase MAX_PACKET_SIZE; Could it be that by calling break right after we print that message, that readSuccess or bPacket has not been updated? The break causes the line: if (!readSuccess) fReorderingBuffer->freePacket(bPacket); to crash because bPacket points to a partially destructed object. (in the freePacket() call on the line "delete packet") While coming up with a good test that makes this crash has proven elusive. The crash itself is very, very consistent. It always crashes on the same line after printing the exact same error. This error seemed to just show up about 6 months ago but way to many things changed to make any correlation, updateing live555 on 3/07 did not change it. I think I just have a certain camera brand that tends to trigger it more often than others now. I am trying to go thru the code and figure it out, but I was hoping you could take a look at that section and see if anything pops out at you. This is a low quality H264 stream without audio from a security camera multichannel encoder. It purposely has a few channels without video which forces re-connections. The bandwidth is very low so the Max_Packet_SIZE error makes me speculate an occasional long stream of garbage data causing trouble finding end of a valid packet Thus the reason it takes days to show up. This crash occurs often enough to be a real game killer. Sometimes it will happen 3 times in an hour but most the time it shows up after about 2-3 days of operation. Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Sun Apr 21 05:14:57 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Apr 2013 05:14:57 -0700 Subject: [Live-devel] Access violation during ReorderPacketBuffer::freepacket In-Reply-To: <615FD77639372542BF647F5EBAA2DBC225309264@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC225309264@IL-BOL-EXCH01.smartwire.com> Message-ID: <922CA3BA-5B71-4137-9B7C-F4401667C341@live555.com> > It is ALWAYS immediately follows the error message : > > MultiFramedRTPSource error: Hit limit when reading incoming packet over TCP. Increase MAX_PACKET_SIZE; That turned out to be useful information. (It's a pity you didn't mention that before :-) > Could it be that by calling break right after we print that message, that readSuccess or bPacket has not been updated? No, not quite. However, there *was* a bug in the code that may have caused the problem that you were seeing. I've just installed a new version of the code (2013.04.21) that should fix this. You should also upgrade your *server* (i.e., camera) to use the latest version of the LIVE555 code (if it is using our code, which it likely is). If you do that, this will probably eliminate the "Hit limit when reading incoming packet over TCP" error message that you're seeing in your client. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Sun Apr 21 07:59:46 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Sun, 21 Apr 2013 14:59:46 +0000 Subject: [Live-devel] Access violation during ReorderPacketBuffer::freepacket In-Reply-To: <922CA3BA-5B71-4137-9B7C-F4401667C341@live555.com> References: <615FD77639372542BF647F5EBAA2DBC225309264@IL-BOL-EXCH01.smartwire.com> <922CA3BA-5B71-4137-9B7C-F4401667C341@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC22530981A@IL-BOL-EXCH01.smartwire.com> Thank you very much! I will update immediately. Unfortunately the cameras themselves are purchased both by us and resold and out of band by the customer. Some can and are willing to update, others are not even open to it. This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Sunday, April 21, 2013 7:15 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Access violation during ReorderPacketBuffer::freepacket It is ALWAYS immediately follows the error message : MultiFramedRTPSource error: Hit limit when reading incoming packet over TCP. Increase MAX_PACKET_SIZE; That turned out to be useful information. (It's a pity you didn't mention that before :-) Could it be that by calling break right after we print that message, that readSuccess or bPacket has not been updated? No, not quite. However, there *was* a bug in the code that may have caused the problem that you were seeing. I've just installed a new version of the code (2013.04.21) that should fix this. You should also upgrade your *server* (i.e., camera) to use the latest version of the LIVE555 code (if it is using our code, which it likely is). If you do that, this will probably eliminate the "Hit limit when reading incoming packet over TCP" error message that you're seeing in your client. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Sun Apr 21 08:54:58 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Sun, 21 Apr 2013 15:54:58 +0000 Subject: [Live-devel] Feature Requests Message-ID: <615FD77639372542BF647F5EBAA2DBC2253098AB@IL-BOL-EXCH01.smartwire.com> I am more than a few lists and can't remember for sure, but was it this list that asked about possible feature requests after the usage survey? At the time I couldn't think of any, but todays update reminded me of one. First a confession. Every update I modify Boolean.hh. The addition of || (defined(_MSC_VER) && _MSC_VER >= 1400) // MSVC++ 8.0, Visual Studio 2005 and higher On line 19 some time ago. always breaks my build. I use boost 1_49 and 1_53 in my projects and that is a template argument so as a #define(text substitution), it breaks my builds. Funny thing is I am building on windows in Visual Studio 2010! I don't know what a good solution is, so I have been hesitant to mention this. Leave it to the user of the library? or begin namespacing with this little guy? Ps I tried being first or using the #ifndef wrapper , but that does not work deterministically. Maybe an #ifdef NEED_LIVE555_BOOLEAN wrapper and let us #define or not? Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Sun Apr 21 12:39:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Apr 2013 12:39:35 -0700 Subject: [Live-devel] Access violation during ReorderPacketBuffer::freepacket In-Reply-To: <615FD77639372542BF647F5EBAA2DBC22530981A@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC225309264@IL-BOL-EXCH01.smartwire.com> <922CA3BA-5B71-4137-9B7C-F4401667C341@live555.com> <615FD77639372542BF647F5EBAA2DBC22530981A@IL-BOL-EXCH01.smartwire.com> Message-ID: > Unfortunately the cameras themselves are purchased both by us and resold and out of band by the customer. > Some can and are willing to update, others are not even open to it. However, if the camera is using the "LIVE555 Streaming Media" software, then - under the terms of the LGPL - their manufacturer *must* provide a way to upgrade this software. Please remind them of this. In any case, the only reason why you ever saw the "Hit limit when reading incoming packet over TCP" was because the camera's data rate exceeded the capacity of the network (between the camera and your client). If this happens, you WILL lose data. Nothing - not even the use of RTP-over-TCP - can prevent this. (Upgrading the camera's software will merely make the data loss happen a little more cleanly.) If your camera's data rate exceeds the capacity of your network, you (obviously) need to reduce the camera's data rate. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Apr 21 13:23:51 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Apr 2013 13:23:51 -0700 Subject: [Live-devel] Feature Requests In-Reply-To: <615FD77639372542BF647F5EBAA2DBC2253098AB@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC2253098AB@IL-BOL-EXCH01.smartwire.com> Message-ID: <28E4BE38-1D9E-499F-B678-AF699AAECA9A@live555.com> > First a confession. Every update I modify Boolean.hh. The addition of > || (defined(_MSC_VER) && _MSC_VER >= 1400) // MSVC++ 8.0, Visual Studio 2005 and higher > > On line 19 some time ago. always breaks my build. I made this change in May 2012 because someone noted that "MSVC++ 8.0, Visual Studio 2005 and higher" defined its own Boolean type - called "bool" - and they wanted to use this as "Boolean" instead of our own definition (as "unsigned char"). So why is this breaking for you. Do you not have "bool" defined after all? Do you think I should change the "MSC_VER" test in some way? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tboonefisher at clear.net Sun Apr 21 13:21:45 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Sun, 21 Apr 2013 15:21:45 -0500 Subject: [Live-devel] Access violationduring ReorderPacketBuffer::freepacket In-Reply-To: References: <615FD77639372542BF647F5EBAA2DBC225309264@IL-BOL-EXCH01.smartwire.com> <922CA3BA-5B71-4137-9B7C-F4401667C341@live555.com> <615FD77639372542BF647F5EBAA2DBC22530981A@IL-BOL-EXCH01.smartwire.com> Message-ID: <0B1C4126C37B49468A4FA3267578E621@tbxpnotebook> >Unfortunately the cameras themselves are purchased both by us and resold and out of band by the customer. >Some can and are willing to update, others are not even open to it. >However, if the camera is using the "LIVE555 Streaming Media" software, then - under the terms of the LGPL - their manufacturer *must* provide a way to upgrade this software. Please remind them of this. >In any case, the only reason why you ever saw the "Hit limit when reading incoming packet over TCP" was because the camera's data rate exceeded the capacity of the network (between the camera and >your >client). If this happens, you WILL lose data. Nothing - not even the use of RTP-over-TCP - can prevent this. (Upgrading the camera's software will merely make the data loss happen a little more >cleanly.) >If your camera's data rate exceeds the capacity of your network, you (obviously) need to reduce the camera's data rate. So this applies to Foscam? I forwarded your comments to their tech support and so far, have no response. T Fisher -------------- next part -------------- An HTML attachment was scrubbed... URL: From nambirajan.manickam at i-velozity.com Sun Apr 21 21:21:42 2013 From: nambirajan.manickam at i-velozity.com (Nambirajan) Date: Mon, 22 Apr 2013 09:51:42 +0530 Subject: [Live-devel] Concurrent streaming in Live555 Media Server Message-ID: <000001ce3f10$ec863c90$c592b5b0$@manickam@i-velozity.com> Dear Mr. Ross Finlayson, We are running Live555 Media Server on a RedHat Linux 6 version. Our Hardware is Intel Pentium Core2 Duo processor running at 2.93 GHz with 2 GB RAM. We are running client application ( openRTSP ) on multiple systems. We are observing this issue. We are launching one by one openRTSP client on systems. The Live555 Media Server is running on our Server. On each client application launch on the client system, the CPU usage slowly increases on the Server. For example for the first client launch, the CPU utilization on the Server goes to 1.3 ~ 1.7%. When we reach 63 client put together on different system, the CPU usage in the Server system reaches 92%. The movie freezes on the first client system. We are not able to understand the issue. We are trying to increase the scalability of the Live555Media Server to handle 5000 to 10000 client simultaneously. Can you please give us a clue to handle this issue. Thanks for your continuous support. Best Regards, M. Nambirajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Apr 21 22:27:34 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Apr 2013 22:27:34 -0700 Subject: [Live-devel] Concurrent streaming in Live555 Media Server In-Reply-To: <000001ce3f10$ec863c90$c592b5b0$@manickam@i-velozity.com> References: <000001ce3f10$ec863c90$c592b5b0$@manickam@i-velozity.com> Message-ID: Issues like this are usually caused by you running into some operating-system-imposed limit. See, for example http://www.live555.com/liveMedia/faq.html#scalability Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Szoke at beecomputing.com Mon Apr 22 00:05:13 2013 From: Szoke at beecomputing.com (Szoke) Date: Mon, 22 Apr 2013 09:05:13 +0200 Subject: [Live-devel] Concurrent streaming in Live555 Media Server In-Reply-To: References: <000001ce3f10$ec863c90$c592b5b0$@manickam@i-velozity.com> Message-ID: <5174E129.8080500@BeeComputing.com> Hi everyone, Sorry for such a long message, but a short presentation may interest some of you. I'm following this list for years, as I am involved in a project using IP cameras to film wildlife (bird nesting, can be seen on http://www.solon.be/category/la-cigogne-noire/) We are using very-low consumption linutop computers for 3 years. Until now we were using the linutop OS, and VLC to record videos. Major problems remained : videos were hatched at high resolution and no way to get the audio track. Shifting to Lubuntu allowed using the latest libavcodec-extra package, which fixed the sound issue. Testing openRTSP to get the video and audio streams showed that the input buffer of 100 kB was too small. After downloading the live555 source code, rebuilding openRTSP with bigger buffers, everything worked fine. (easy to say, not that easy to do for a senior Windows developer like me discovering linux development...) Under Lubuntu and MacOS, the only remaining problem is a lack of synchronization between image and sound : for 60 s of recording, the videostops after about 55 s and the audio after 60 s. The command line : openRTSP -d 60 -i -w 1280 -h 960 -f 25 "rtsp://192.168.1.200/HD" > "/media/szoke/CORSAIR/srce_1280-960-25.avi" Without the -f option, synchronization is worse. Note that the camera is not sending exactly 25 fps, but usually a little less, depending in the light intensity. First question : how can I fix the synchronization problem ? Second issue : This morning I tested the result files under Windows 7. - AviFxP tells me that the files are correct. - VLC 2.0.6 cannot display the video, but the audio is OK - Avidemux 2.6.3 displays nothing - WindowsMediaPlayer displays the video nearly properly (every 2 secs there is light flashing, dues to GOP at 50 frames I guess), but the sound is terrible. So I cannot use the openRTSP result files under Windows. Such a file can be downloaded here : (1 minute, 18 MB) www.beecomputing.com/download/srce_1280-960-25-night-and-day%20mozart.avi If someone has a good tool to check the file content and tell me what's wrong ? Thanks a lot in advance for any help, Stan From finlayson at live555.com Mon Apr 22 00:17:32 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Apr 2013 00:17:32 -0700 Subject: [Live-devel] Concurrent streaming in Live555 Media Server In-Reply-To: <5174E129.8080500@BeeComputing.com> References: <000001ce3f10$ec863c90$c592b5b0$@manickam@i-velozity.com> <5174E129.8080500@BeeComputing.com> Message-ID: <35B07DDF-9C33-4BF2-AF3C-BAEB084B22A0@live555.com> > Testing openRTSP to get the video and audio streams showed that the input buffer of 100 kB was too small. > After downloading the live555 source code, rebuilding openRTSP with bigger buffers FYI, you don't need to 'rebuild' the "openRTSP" code to get this. "openRTSP" already has a command-line option -b that will do this. See http://www.live555.com/openRTSP/#other-options Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Szoke at beecomputing.com Mon Apr 22 00:46:16 2013 From: Szoke at beecomputing.com (Szoke) Date: Mon, 22 Apr 2013 09:46:16 +0200 Subject: [Live-devel] Concurrent streaming in Live555 Media Server In-Reply-To: <35B07DDF-9C33-4BF2-AF3C-BAEB084B22A0@live555.com> References: <000001ce3f10$ec863c90$c592b5b0$@manickam@i-velozity.com> <5174E129.8080500@BeeComputing.com> <35B07DDF-9C33-4BF2-AF3C-BAEB084B22A0@live555.com> Message-ID: <5174EAC8.7040900@BeeComputing.com> Thanks Ross, Reading the documentation, I didn't catch that the -b option was also impacting the H264 File Sink class. Stan On 22/04/2013 09:17, Ross Finlayson wrote: >> Testing openRTSP to get the video and audio streams showed that the >> input buffer of 100 kB was too small. >> After downloading the live555 source code, rebuilding openRTSP with >> bigger buffers > > FYI, you don't need to 'rebuild' the "openRTSP" code to get this. > "openRTSP" already has a command-line option > -b > that will do this. See http://www.live555.com/openRTSP/#other-options > > > 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 Subhankar_Saha at mindtree.com Mon Apr 22 02:04:56 2013 From: Subhankar_Saha at mindtree.com (Subhankar Saha) Date: Mon, 22 Apr 2013 09:04:56 +0000 Subject: [Live-devel] ProxyServerMediaSession Questions Message-ID: Hello, I sincerely apologize if the following questions have been asked before here. If these have been asked and answered, I will be very grateful if someone can point me to appropriate discussion thread(s). We are trying to build a system that acts like multi-channel encoder - it accepts RTSP streams from a number of camera, and, streams out the same to another network for viewing. The ProxyServerMediaSession class meets our requirement appropriately, and we have written our own application looking at the example code given. This is how we instantiate the server, when we start our software or when a camera is added: static ProxyServerMediaSession* sms [MAX_STREAMS]; for (sidx = 0; sidx < MAX_STREAMS; sidx ++) { ... /* Get Stream Name */ sprintf (streamName, "Stream-%d", (sidx+1)); /* Create Server Media Session */ sms[sidx] = ProxyServerMediaSession::createNew ( *env, rtspServer, streamer_url[sidx], streamName ); /* Add Server Media Session to RTSP Server */ rtspServer->addServerMediaSession (sms[sidx]); ... } Now, when we need to close down the Server, this is what we do: for (sidx = 0; sidx < MAX_STREAMS; sidx ++) { ... /* Clean up */ rtspServer->deleteServerMediaSession (sms[sidx]); ... } Question#1: When we close our server, we do not see the RTCP BYE being sent to the downstream clients viewing the streams from the server. Is this an issue with 'deleteServerMediaSession'? Or, should we be calling something else, or, do more here? It appears the system waits for the clients to timeout and close the connections themselves. And when client closes the connection, after waiting an amount of time wanting data to come, some cleanups are triggered on the server side. But ideally, we would like to implement a closure method in which client connections are duly closed on user action on the server (server shutdown or camera deletion). Question#2: We have a requirement to make the Server a multicast UDP server. From looking at the code, it appears ProxyServerMediaSession makes use of OnDemandServerMediaSubsession ... which is unicast. Is there any plan to support multicasting? If no, could someone guide us on steps needed to get multicast supported? Thank you very much in advance. Best regards, Subhankar. ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From conchi.ap at vaelsys.com Mon Apr 22 03:15:41 2013 From: conchi.ap at vaelsys.com (Conchi Abasolo) Date: Mon, 22 Apr 2013 12:15:41 +0200 Subject: [Live-devel] decodeURL error Message-ID: Hello, After seeing a strange behaviour of the library decoding '%' sequences in RTSP URL stream names, it seems to be an error in the decodeURL method at RTSPCommon.cpp You can see the following sentences at the code: // We saw a % followed by 2 hex digits, so we copy the literal hex value into the URL, then advance the cursor past it: char hex[3]; hex[0] = cursor[1]; hex[2] = cursor[2]; hex[3] = '\0'; The indexes of the "hex" array are wrong, it goes from 0 to 2, without saving any value at "1" position, must be as follows // We saw a % followed by 2 hex digits, so we copy the literal hex value into the URL, then advance the cursor past it: char hex[3]; hex[0] = cursor[1]; hex[1] = cursor[2]; hex[2] = '\0'; Could you please fix this in next releases? Thank you in advance, Conchi -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 22 08:12:31 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Apr 2013 08:12:31 -0700 Subject: [Live-devel] decodeURL error In-Reply-To: References: Message-ID: > Could you please fix this in next releases? Oops - my mistake. This is fixed in version 2013.04.22, released now. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 22 08:15:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Apr 2013 08:15:05 -0700 Subject: [Live-devel] Feature Requests In-Reply-To: <28E4BE38-1D9E-499F-B678-AF699AAECA9A@live555.com> References: <615FD77639372542BF647F5EBAA2DBC2253098AB@IL-BOL-EXCH01.smartwire.com> <28E4BE38-1D9E-499F-B678-AF699AAECA9A@live555.com> Message-ID: <9DA243AC-7D46-4EC8-8501-D2A30A6DE489@live555.com> >> First a confession. Every update I modify Boolean.hh. The addition of >> || (defined(_MSC_VER) && _MSC_VER >= 1400) // MSVC++ 8.0, Visual Studio 2005 and higher >> >> On line 19 some time ago. always breaks my build. > > I made this change in May 2012 because someone noted that "MSVC++ 8.0, Visual Studio 2005 and higher" defined its own Boolean type - called "bool" - and they wanted to use this as "Boolean" instead of our own definition (as "unsigned char"). OK, in the latest release - version 2013.04.22 - I've changed this to #if defined(__BORLANDC__) || (!defined(USE_LIVE555_BOOLEAN) && defined(_MSC_VER) && _MSC_VER >= 1400) So, if you don't want to use "bool", you can do so by defining "USE_LIVE555_BOOLEAN" on the command line Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 22 08:34:57 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Apr 2013 08:34:57 -0700 Subject: [Live-devel] Warning: The old 'synchronous' "RTSPClient" interface will be removed, starting on June 1st, 2013 Message-ID: <3BA52EAE-A0F1-4177-960F-86D8CC71E405@live555.com> On June 1st, 2013, it will be just over three years since the "RTSPClient" class was changed to use an asynchronous (i.e., non-blocking) interface (and more than 15 months since the old 'synchronous' "RTSPClient" interface was defined, by default, in the code). Starting on that date, the old synchronous "RTSPClient" interface will no longer be available, at all (and will therefore no longer be supported). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 22 23:35:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Apr 2013 23:35:18 -0700 Subject: [Live-devel] ProxyServerMediaSession Questions In-Reply-To: References: Message-ID: Subhankar, Thanks for the note. > Question#1: When we close our server, we do not see the RTCP BYE being sent to the downstream clients viewing the streams from the server. Is this an issue with ?deleteServerMediaSession?? Yes, there was a minor bug in our RTSP server implementation that was preventing this from working. I have now installed a new version (2013.04.23) of the "LIVE555 Streaming Media" code that fixes this. Note that "deleteServerMediaSession()" will now cause a RTCP "BYE" to be sent, but it will *not* cause the client's TCP connection to be closed. The reason for this is that the client is allowed to use the existing TCP connection to make more RTSP requests (e.g., to play some other stream). However, if the client does not make any more RTSP requests over the TCP connection, the TCP connection will eventually be closed down (because of the server's usual 'garbage collection' of inactive TCP connections). > Question#2: We have a requirement to make the Server a multicast UDP server. From looking at the code, it appears ProxyServerMediaSession makes use of OnDemandServerMediaSubsession ? which is unicast. Is there any plan to support multicasting? No. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Tue Apr 23 04:55:10 2013 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Tue, 23 Apr 2013 13:55:10 +0200 Subject: [Live-devel] test.m4e streaming not working anymore In-Reply-To: <5A87FFF4-848A-4341-873F-6BE4CFC069EE@live555.com> Message-ID: <1633470.CYyP0qtxqC@mnmsd> > HOWEVER, with VLC 2.0.6 as the client, the video doesn't render. > Opening VLC's "Messages" log, I see several messages of the form: > avcodec warning: cannot decode one frame ( bytes) The windows version of VLC 2.0.6 is working fine with this stream. But the ubuntu VLC 2.0.6 is not. This is a ffmpeg issue, and it depends which version of ffmpeg was compiled with VLC. So it should be fixed with newer releases. S?bastien. From BYu at drs-rsta.com Tue Apr 23 06:46:06 2013 From: BYu at drs-rsta.com (Yu, Bo) Date: Tue, 23 Apr 2013 13:46:06 +0000 Subject: [Live-devel] low latency transmit Message-ID: Hi, Can MultiFramedRTPSink::sendPacketIfNecessary() be enhanced safely with the following code ? I would like to transmit all packets within one video frame as soon as possible instead of scheduling packet one by one ? uSecondsToGo gets 1 usec but cause the schedule to run and actually add a lot of latency between packets. if (fNoFramesLeft) { // We're done: onSourceClosure(this); } else { if (fOutBuf->haveOverflowData()) { sendNext(this); } else { // We have more frames left to send. Figure out when the next frame // is due to start playing, then make sure that we wait this long before // sending the next packet. struct timeval timeNow; gettimeofday(&timeNow, NULL); int secsDiff = fNextSendTime.tv_sec - timeNow.tv_sec; int64_t uSecondsToGo = secsDiff*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec); if (uSecondsToGo < 0 || secsDiff < 0) { // sanity check: Make sure that the time-to-delay is non-negative: uSecondsToGo = 0; } // Delay this amount of time: nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo, (TaskFunc*)sendNext, this); } } Bo -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Tue Apr 23 05:25:17 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Tue, 23 Apr 2013 14:25:17 +0200 Subject: [Live-devel] Warning: The old 'synchronous' "RTSPClient" interface will be removed, starting on June 1st, 2013 In-Reply-To: <3BA52EAE-A0F1-4177-960F-86D8CC71E405@live555.com> References: <3BA52EAE-A0F1-4177-960F-86D8CC71E405@live555.com> Message-ID: <2722_1366727127_517699D6_2722_2264_1_1BE8971B6CFF3A4F97AF4011882AA255015610CA631B@THSONEA01CMS01P.one.grp> Hi Ross, Thanks a lots for this very nice library and for your quick feedback on the mailing list. Could it be possible from the RTSP callback to get back the context of the RTSPClient owner ? More or less the stuff that is done using a customized RTSPClient in testRTSPClient.cpp or using global variable in playCommon.cpp Perhaps adding some extra parameters in the callback prototype "typedef void (responseHandler)(RTSPClient* rtspClient, int resultCode, char* resultString);" to identify the MediaSession and the MediaSubsession ? or a void * to allow user to specify its arguments ? Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : lundi 22 avril 2013 17:35 ? : LIVE555 Streaming Media - development & use Objet : [Live-devel] Warning: The old 'synchronous' "RTSPClient" interface will be removed, starting on June 1st, 2013 On June 1st, 2013, it will be just over three years since the "RTSPClient" class was changed to use an asynchronous (i.e., non-blocking) interface (and more than 15 months since the old 'synchronous' "RTSPClient" interface was defined, by default, in the code). Starting on that date, the old synchronous "RTSPClient" interface will no longer be available, at all (and will therefore no longer be supported). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 23 08:09:13 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Apr 2013 08:09:13 -0700 Subject: [Live-devel] low latency transmit In-Reply-To: References: Message-ID: > Can MultiFramedRTPSink::sendPacketIfNecessary() be enhanced safely with the following code ? No, because it's not correct. The whole point of the existing code is to delay the sending of the next packet, as appropriate, based on the value of "durationInMicroseconds" that was passed (to "afterGettingFrame()") by the upstream source object. (Note the calculation of "fNextSendTIme" on lines 321-323.) > I would like to transmit all packets within one video frame as soon as possible instead of scheduling packet one by one ? uSecondsToGo gets 1 usec Then the upstream source object must have set a non-zero value of "fDurationInMicroseconds" - which is probably not what you wanted. (Note that if you're streaming from a live input source (as opposed to a file, for example) , then it's OK for it *not* to set "fDurationInMicroseconds", which means that it'll retain its default value of 0. > but cause the schedule to run and actually add a lot of latency between packets. No. If you happen to take longer than expected to get back to this code again, then it'll catch up. That's why we call "gettimeofday()", and compare the result to "fNextSendTime". If the current time happens to be later than "fNextSendTime", then "uSecondsToGo" will be 0, and scheduler will send the next packet ASAP. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 23 08:13:33 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Apr 2013 08:13:33 -0700 Subject: [Live-devel] Warning: The old 'synchronous' "RTSPClient" interface will be removed, starting on June 1st, 2013 In-Reply-To: <2722_1366727127_517699D6_2722_2264_1_1BE8971B6CFF3A4F97AF4011882AA255015610CA631B@THSONEA01CMS01P.one.grp> References: <3BA52EAE-A0F1-4177-960F-86D8CC71E405@live555.com> <2722_1366727127_517699D6_2722_2264_1_1BE8971B6CFF3A4F97AF4011882AA255015610CA631B@THSONEA01CMS01P.one.grp> Message-ID: > Could it be possible from the RTSP callback to get back the context of the RTSPClient owner ? I'm not sure what exactly you mean by 'context of the RTSPClient owner', but - after 3 years now of people using the current "RTSPClient" API - I'm certainly not going to be making any unnecessary changes to it. You can get all the information you want from the "RTSPClient" object (perhaps by subclassing, if necessary, as you noted). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Wed Apr 24 01:25:32 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Wed, 24 Apr 2013 10:25:32 +0200 Subject: [Live-devel] Warning: The old 'synchronous' "RTSPClient" interface will be removed, starting on June 1st, 2013 In-Reply-To: References: <3BA52EAE-A0F1-4177-960F-86D8CC71E405@live555.com> <2722_1366727127_517699D6_2722_2264_1_1BE8971B6CFF3A4F97AF4011882AA255015610CA631B@THSONEA01CMS01P.one.grp> Message-ID: <32108_1366791934_517796FE_32108_6581_1_1BE8971B6CFF3A4F97AF4011882AA255015610CF7391@THSONEA01CMS01P.one.grp> Hi Ross, Thanks for your great support. May I suggest that probably lots of live555 users need to do the same stuff in order to send DESCRIBE,SETUP,PLAY overriding the RTSPClient to get reference to the session. But no problem I could adapt to the available API. Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : mardi 23 avril 2013 17:14 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Warning: The old 'synchronous' "RTSPClient" interface will be removed, starting on June 1st, 2013 Could it be possible from the RTSP callback to get back the context of the RTSPClient owner ? I'm not sure what exactly you mean by 'context of the RTSPClient owner', but - after 3 years now of people using the current "RTSPClient" API - I'm certainly not going to be making any unnecessary changes to it. You can get all the information you want from the "RTSPClient" object (perhaps by subclassing, if necessary, as you noted). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zili.zhou at alcatel-lucent.com Wed Apr 24 03:13:40 2013 From: zili.zhou at alcatel-lucent.com (ZHOU, Zili (Zili)** CTR **) Date: Wed, 24 Apr 2013 12:13:40 +0200 Subject: [Live-devel] Which "Source" subclass and "MediaServerSubsession" subclass should be chose for AAC stream? Message-ID: <847511671F54DE4993965CCD25F38AE36747325EE2@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Hi, I want to transfer AAC stream by RTP-over-TCP to live555 RTSP server, is it practical? If yes which source and sink subclass can be chose? Are there any available existing MediaServerSubsession subclass? Regards, Zili. Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 24 07:47:49 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Apr 2013 07:47:49 -0700 Subject: [Live-devel] Which "Source" subclass and "MediaServerSubsession" subclass should be chose for AAC stream? In-Reply-To: <847511671F54DE4993965CCD25F38AE36747325EE2@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> References: <847511671F54DE4993965CCD25F38AE36747325EE2@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Message-ID: > I want to transfer AAC stream by RTP-over-TCP to live555 RTSP server, is it practical? Yes, except that you don't stream *to* a server (because that's not what servers should be doing). Instead, you stream *from* a server. If your AAC data source already has a RTSP server, then you can either stream from it directly, or - if you wish - use the "LIVE555 Proxy Server" as an intermediary. If, instead, you want to develop you own RTSP server that streams AAC audio, you can do so by writing your own "FramedSource" subclass that delivers AAC audio frames, and feeding it to a "MPEG4GenericRTPSink". See, for example, "ADTSAudioFileServerMediaSubsession.cpp", which shows how this is done when streaming from an ADTS-format AAC file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From BYu at drs-rsta.com Wed Apr 24 08:02:40 2013 From: BYu at drs-rsta.com (Yu, Bo) Date: Wed, 24 Apr 2013 15:02:40 +0000 Subject: [Live-devel] low latency transmit In-Reply-To: References: Message-ID: Not sure how live555 task schedule works but usleep(0) will take some time and once the process give up the CPU and there is no guarantee when it will get back CPU. Bo From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, April 23, 2013 10:09 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] low latency transmit Can MultiFramedRTPSink::sendPacketIfNecessary() be enhanced safely with the following code ? No, because it's not correct. The whole point of the existing code is to delay the sending of the next packet, as appropriate, based on the value of "durationInMicroseconds" that was passed (to "afterGettingFrame()") by the upstream source object. (Note the calculation of "fNextSendTIme" on lines 321-323.) I would like to transmit all packets within one video frame as soon as possible instead of scheduling packet one by one ? uSecondsToGo gets 1 usec Then the upstream source object must have set a non-zero value of "fDurationInMicroseconds" - which is probably not what you wanted. (Note that if you're streaming from a live input source (as opposed to a file, for example) , then it's OK for it *not* to set "fDurationInMicroseconds", which means that it'll retain its default value of 0. but cause the schedule to run and actually add a lot of latency between packets. No. If you happen to take longer than expected to get back to this code again, then it'll catch up. That's why we call "gettimeofday()", and compare the result to "fNextSendTime". If the current time happens to be later than "fNextSendTime", then "uSecondsToGo" will be 0, and scheduler will send the next packet ASAP. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zili.zhou at alcatel-lucent.com Thu Apr 25 03:37:15 2013 From: zili.zhou at alcatel-lucent.com (ZHOU, Zili (Zili)** CTR **) Date: Thu, 25 Apr 2013 12:37:15 +0200 Subject: [Live-devel] Which "Source" subclass and "MediaServerSubsession" subclass should be chose for AAC stream? In-Reply-To: References: <847511671F54DE4993965CCD25F38AE36747325EE2@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Message-ID: <847511671F54DE4993965CCD25F38AE36747326023@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Ross, Thanks for you reply. I still have some questions. Assume there is an AAC file a.aac exist on RTSP server, and an application continue to append data into the file. Can RTSP server stream from this AAC file at the same time? Can RTSP server stream from server's *memory* directly? Thanks for your time. ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, April 24, 2013 10:48 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Which "Source" subclass and "MediaServerSubsession" subclass should be chose for AAC stream? I want to transfer AAC stream by RTP-over-TCP to live555 RTSP server, is it practical? Yes, except that you don't stream *to* a server (because that's not what servers should be doing). Instead, you stream *from* a server. If your AAC data source already has a RTSP server, then you can either stream from it directly, or - if you wish - use the "LIVE555 Proxy Server" as an intermediary. If, instead, you want to develop you own RTSP server that streams AAC audio, you can do so by writing your own "FramedSource" subclass that delivers AAC audio frames, and feeding it to a "MPEG4GenericRTPSink". See, for example, "ADTSAudioFileServerMediaSubsession.cpp", which shows how this is done when streaming from an ADTS-format AAC file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 25 07:44:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 25 Apr 2013 07:44:05 -0700 Subject: [Live-devel] Which "Source" subclass and "MediaServerSubsession" subclass should be chose for AAC stream? In-Reply-To: <847511671F54DE4993965CCD25F38AE36747326023@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> References: <847511671F54DE4993965CCD25F38AE36747325EE2@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> <847511671F54DE4993965CCD25F38AE36747326023@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Message-ID: <60B771DB-2804-4163-B1BF-21AFEC1082BF@live555.com> > Assume there is an AAC file a.aac exist on RTSP server, and an application continue to append data into the file. Can RTSP server stream from this AAC file at the same time? I *think* that this will work (if the AAC audio file is in ADTS format), but I don't know for sure. > Can RTSP server stream from server?s *memory* directly? Yes, we have a class "ByteStreamMemoryBufferSource" that the server could use for input. (Such a buffer is fixed in size, however.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcv5 at students.calvin.edu Thu Apr 25 10:50:42 2013 From: rcv5 at students.calvin.edu (Bob VanLonkhuyzen) Date: Thu, 25 Apr 2013 13:50:42 -0400 Subject: [Live-devel] Live555 for RTSP iOS app Message-ID: Hello, I am working on an app to take an RTSP audio stream over WiFi and play it to the user. This will all be done in iOS. I have used testRTSPClient as a model, but I am not sure how to incorporate the iOS audio streaming built-in capabilities (AudioFileStreamOpen and AudioFileStreamParseBytes), or if this is even the correct way to read the streamed data form the filesink. Any tips or assistance on reading form the filesink on iOS would be greatly appreciated. Thank you for your help, Bob VanLonkhuyzen -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith at cognitec.com Fri Apr 26 01:20:49 2013 From: smith at cognitec.com (Robert Smith) Date: Fri, 26 Apr 2013 10:20:49 +0200 Subject: [Live-devel] Having trouble implementing a live unicast stream In-Reply-To: <5179698C.5000503@cognitec.com> References: <5179698C.5000503@cognitec.com> Message-ID: <517A38E1.8020709@cognitec.com> I am implementing an RTSP server to stream live H264 video via either multicast or unicast RTP. My multicast solution is working fine but the unicast stream is giving me trouble. I've read the FAQ and based on this I created a test program like so: 1) Created an OnDemandServerMediaSubsession subclass which holds a FramedSource* provided in the class constructor and returns this pointer in it's 'createNewStreamSource' method as well as setting the estBitrate parameter. 'createNewRTPSink' is identical to that of H264FileServerMediaSubsession. The 'reuseFirstSource' parameter is set to 'True'. 2) Modified testOnDemandRTSPServer to create a ByteStreamFileSource, wrap it in an H264VideoStreamFramer and pass it to my OnDemandServerMediaSubsession subclass. I had expected this to work but instead it crashes in a call to 'H264VideoRTPSink::sourceIsCompatibleWithUs', this is the top of the stack trace: #0 0x000000000045da92 in typeinfo name for HashTable::Iterator () #1 0x0000000000000207 in ?? () #2 0x000000000067d3f0 in ?? () #3 0x000000000040776f in H264VideoRTPSink::sourceIsCompatibleWithUs (this=0x67d4a0, source=...) at H264VideoRTPSink.cpp:101 #4 0x0000000000406b85 in MediaSink::startPlaying (this=0x67d4a0, source=..., afterFunc= 0x415333 , afterClientData=0x67d090) at MediaSink.cpp:70 When I create a new ByteSteamFileSource/H264VideoStreamFramer inside the 'createNewStreamSource' method ala H264FileServerMediaSubsession it works as expected. From this I take it that each call to 'createNewStreamSource' should return a pointer to a different object, but then I'm unsure how this works when there is only a single source, I thought that using reuseFirstSource = True would mean that I could use a single source object. I've obviously misunderstood the instructions in the FAQ so it would be great if you could point me in the right direction. Regards, Robert Smith. From finlayson at live555.com Fri Apr 26 02:00:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Apr 2013 02:00:36 -0700 Subject: [Live-devel] Having trouble implementing a live unicast stream In-Reply-To: <517A38E1.8020709@cognitec.com> References: <5179698C.5000503@cognitec.com> <517A38E1.8020709@cognitec.com> Message-ID: <1FEAAA9D-CEDD-40F9-86E3-BB0CF9615150@live555.com> > When I create a new ByteSteamFileSource/H264VideoStreamFramer inside the 'createNewStreamSource' method ala H264FileServerMediaSubsession it works as expected. You should continue to do this. > From this I take it that each call to 'createNewStreamSource' should return a pointer to a different object, but then I'm unsure how this works when there is only a single source, I thought that using reuseFirstSource = True would mean that I could use a single source object. Not quite. Setting "reuseFirstSource" to "True" means that only one source object exists - *at a time*. However, the server code (when streaming H.264 video) initializes by creating a dummy source object, then destroys it, then creates another source object that it will use for subsequent streaming. This source object may also get destroyed later, if all clients that are using it end up doing a RTSP "TEARDOWN" on the stream. If that happens, the next client (if any) will end up causing a new source object to be created. And so on... So, in summary: You need to be prepared for "createNewStreamSource()" to be called multiple times, and for the resulting source object to be destroyed multiple times. (However, because you've set "reuseFirstSource" to "True", you can expect no more than one such source object to be in existence at any one time.) Also, because you're streaming H.264 video, you may wish (in your "createNewRTPSink()" virtual function implementation) to use one of the alternative forms of "H264VideoRTPSink::createNew()" that take the stream's SPS and PPS NAL units - if you know them - as parameter. See "liveMedia/include/H264VideoRTPSink.hh". If you instead use the regular "H264VideoRTPSink::createNew()" (that doesn't take these extra parameters), then your code will still work, but only if your H.264 encoder generates SPS and PPS NAL units 'in band', and these occur frequently. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith at cognitec.com Fri Apr 26 08:45:05 2013 From: smith at cognitec.com (Robert Smith) Date: Fri, 26 Apr 2013 17:45:05 +0200 Subject: [Live-devel] Having trouble implementing a live unicast stream In-Reply-To: <1FEAAA9D-CEDD-40F9-86E3-BB0CF9615150@live555.com> References: <5179698C.5000503@cognitec.com> <517A38E1.8020709@cognitec.com> <1FEAAA9D-CEDD-40F9-86E3-BB0CF9615150@live555.com> Message-ID: <517AA101.4000800@cognitec.com> Thanks Ross, I have made some changes to my architecture and it is working ok now, although I spent quite a while trying to figure out why the RTPSink wasn't starting which turned out to be because i forgot to wrap my source in a Framer when I made the changes; should I have expected to see error messages when isSourceCompatibleWithUs() failed? As a side note: I'm having trouble understanding what happens when DeviceSource triggers it's event trigger.. The trigger calls deliverFrame(), The first line of deliverFrame() is: if (!isCurrentlyAwaitingData()) return; and unless I'm mistaken, this is always going to return unless in a call to getNextFrame(). Does this trigger have other side effects? I'm inclined to remove the trigger to see if it has any effect but that will have to wait for next week. Thanks for the quick reply btw, it made a big difference for me today. Regards, Robert Smith. From tboonefisher at clear.net Fri Apr 26 09:32:25 2013 From: tboonefisher at clear.net (tboonefisher at clear.net) Date: Fri, 26 Apr 2013 11:32:25 -0500 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: <116624BF-DC40-4FA8-B616-C1C07B6F6827@live555.com> References: <83B9617CAE5B45F9A1F79D52ECF9F25D@tbxpnotebook> <116624BF-DC40-4FA8-B616-C1C07B6F6827@live555.com> Message-ID: <4C7948BD431B4B909F8938F2D397B6E5@tbxpnotebook> From: Ross Finlayson Sent: Friday, April 05, 2013 7:10 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream I am experimenting with the testRTSPClient app to develop a DirectShow source filter to connect to a network camera outputting an H.264 video stream. The app successfully connects to the camera and shows the following continuous output: ... Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.117119 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 411 bytes. Presentation time: 1365102232.186298 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.226244 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 458 bytes. Presentation time: 1365102232.375975 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.359869 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.465869 Stream "rtsp://192.168.1.7:65534/videoSub/"; audio/PCMU: Received 960 bytes. Presentation time: 1365102232.585744 Stream "rtsp://192.168.1.7:65534/videoSub/"; video/H264: Received 950 bytes. Presentation time: 1365102232.666086 ... Initially, I am only interested in the video portion of the stream. Using the library, what is the most efficient way to get access to the H.264 portion of the stream >>Because this is a Frequently Asked Question, I have now added an entry for it to the FAQ. See: >>http://www.live555.com/liveMedia/faq.html#testRTSPClient-how-to-decode-data Re-reading your explanation above, in my ContinueAfterSETUP method, should I do the following: unsigned n_records=0; const char* sps = scs.subsession->fmtp_spropparametersets(); SPropRecord* pSPropRecord = parseSPropParameterSets( sps, n_records ); Now what do I send to my downstream decoder ?? Thanks, Tom Fisher -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 26 12:11:14 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Apr 2013 12:11:14 -0700 Subject: [Live-devel] Having trouble implementing a live unicast stream In-Reply-To: <517AA101.4000800@cognitec.com> References: <5179698C.5000503@cognitec.com> <517A38E1.8020709@cognitec.com> <1FEAAA9D-CEDD-40F9-86E3-BB0CF9615150@live555.com> <517AA101.4000800@cognitec.com> Message-ID: <6DC81E9E-59B9-4A0A-8A03-FD13C77EED2F@live555.com> > As a side note: I'm having trouble understanding what happens when DeviceSource triggers it's event trigger.. > > The trigger calls deliverFrame(), The first line of deliverFrame() is: > > if (!isCurrentlyAwaitingData()) return; > > and unless I'm mistaken, this is always going to return unless in a call to getNextFrame(). That's true - except replace "unless in a call to getNextFrame()" with "unless a call to getNextFrame() has happened, but the corresponding frame delivery completion (i.e., the call to "FramedSource::afterGetting()") has not yet happened". > Does this trigger have other side effects? I'm inclined to remove the trigger to see if it has any effect If you remove the event trigger (called from another thread), then you won't get any frames delivered if "getNextFrame()" (and thus "doGetNextFrame()") is ever called when there are no new frames available! That's why you need it! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 26 12:16:28 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Apr 2013 12:16:28 -0700 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: <4C7948BD431B4B909F8938F2D397B6E5@tbxpnotebook> References: <83B9617CAE5B45F9A1F79D52ECF9F25D@tbxpnotebook> <116624BF-DC40-4FA8-B616-C1C07B6F6827@live555.com> <4C7948BD431B4B909F8938F2D397B6E5@tbxpnotebook> Message-ID: >> Using the library, what is the most efficient way to get access to the H.264 portion of the stream > > >>Because this is a Frequently Asked Question, I have now added an entry for it to the FAQ. See: > >>http://www.live555.com/liveMedia/faq.html#testRTSPClient-how-to-decode-data > > Re-reading your explanation above, in my ContinueAfterSETUP method, should I do the following: > > unsigned n_records=0; > const char* sps = scs.subsession->fmtp_spropparametersets(); > SPropRecord* pSPropRecord = parseSPropParameterSets( sps, n_records ); > > Now what do I send to my downstream decoder ?? Do something like: for (unsigned i = 0; i < n_records; ++i) { pass the NAL unit pointed to by "psPropRecord[i]->sPropBytes" (of length "psPropRecord[i]->sPropLength") to your decoder } delete[] psPropRecord; Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeremiah.Morrill at econnect.tv Fri Apr 26 12:22:44 2013 From: Jeremiah.Morrill at econnect.tv (Jeremiah Morrill) Date: Fri, 26 Apr 2013 19:22:44 +0000 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: <4C7948BD431B4B909F8938F2D397B6E5@tbxpnotebook> References: <83B9617CAE5B45F9A1F79D52ECF9F25D@tbxpnotebook> <116624BF-DC40-4FA8-B616-C1C07B6F6827@live555.com> <4C7948BD431B4B909F8938F2D397B6E5@tbxpnotebook> Message-ID: <80C795F72B3CB241A9256DABF0A04EC53BB1CA4B@CH1PRD0710MB391.namprd07.prod.outlook.com> After you parse the nal records from parseSPropParameterSets, store them. For each sample that comes through, construct the buffer you send to your upstream decoder like this: Where start_code is 4 bytes 0x00, 0x00, 0x00, 0x01 [start_code][NAL_record_1][start_code][NAL_record_2][start_code][sample_data] There may be some more correct way, but this has worked for me. Also some h264 decoders are different in how they except NAL units, so you may want to check with the documentation. -Jer -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 26 12:25:01 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Apr 2013 12:25:01 -0700 Subject: [Live-devel] Having trouble implementing a live unicast stream In-Reply-To: <6DC81E9E-59B9-4A0A-8A03-FD13C77EED2F@live555.com> References: <5179698C.5000503@cognitec.com> <517A38E1.8020709@cognitec.com> <1FEAAA9D-CEDD-40F9-86E3-BB0CF9615150@live555.com> <517AA101.4000800@cognitec.com> <6DC81E9E-59B9-4A0A-8A03-FD13C77EED2F@live555.com> Message-ID: One more thing. Because your input device (H.264 encoder) is (I presume) delivering discrete NAL units (one at a time), rather than an unstructured byte stream, be sure to use a "H264VideoStreamDiscreteFramer", not a "H264VideoStreamFramer". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Fri Apr 26 13:02:40 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Fri, 26 Apr 2013 20:02:40 +0000 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: <80C795F72B3CB241A9256DABF0A04EC53BB1CA4B@CH1PRD0710MB391.namprd07.prod.outlook.com> References: <83B9617CAE5B45F9A1F79D52ECF9F25D@tbxpnotebook> <116624BF-DC40-4FA8-B616-C1C07B6F6827@live555.com> <4C7948BD431B4B909F8938F2D397B6E5@tbxpnotebook> <80C795F72B3CB241A9256DABF0A04EC53BB1CA4B@CH1PRD0710MB391.namprd07.prod.outlook.com> Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010EA578@postal.sonicfoundry.net> I decode H.264 from a network camera. My decoder wants SPS/PPS once before the first I-frame in band delivered. So I wait until I get the first I-frame and then insert 0x0000001/SPS/0x0000001/PPS before the I-frame. Interestingly - one of the cameras I test with sends SPS/PPS inside the RTP stream - I drop those SPS/PPSs. But you are right - it's decoder dependent. Markus. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremiah Morrill Sent: Friday, April 26, 2013 2:23 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream After you parse the nal records from parseSPropParameterSets, store them. For each sample that comes through, construct the buffer you send to your upstream decoder like this: Where start_code is 4 bytes 0x00, 0x00, 0x00, 0x01 [start_code][NAL_record_1][start_code][NAL_record_2][start_code][sample_data] There may be some more correct way, but this has worked for me. Also some h264 decoders are different in how they except NAL units, so you may want to check with the documentation. -Jer -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 26 16:45:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Apr 2013 16:45:09 -0700 Subject: [Live-devel] Reminder: A new survey: How would you improve the "LIVE555 Streaming Media" software Message-ID: I'm pleased to report that almost 99% of you think that the "LIVE555 Streaming Media" software is perfect, and that no new features should be added. How do I know this? Because, so far, only 20 of the 1881 people on this mailing list have responded to the new survey: How would you improve the "LIVE555 Streaming Media" software: https://www.surveymonkey.com/s/LIVE555_new_features If, by chance, you're not one of those who feels that the software is perfect :-), please feel free to take the survey. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at patrick-fischer.de Sat Apr 27 23:18:27 2013 From: info at patrick-fischer.de (Patrick Fischer) Date: Sun, 28 Apr 2013 08:18:27 +0200 Subject: [Live-devel] trickplay with MultiFileSources In-Reply-To: <51783AB7.6090303@gmx.de> References: <51783AB7.6090303@gmx.de> Message-ID: <517CBF33.8060303@patrick-fischer.de> Hello, this is my first post on this mailinglist. I'm trying to use lib555 to stream a mpeg ts recordings which are split up into multifiles. So I have to use ByteStreamMultiFileSource which works after some changes. The problem is that ByteStreamMultiFileSource can't seek (needed for trickplay) So i have add a seekToByteAbsolute to my own ByteStreamMultiFileSource Class. The problem is to know which file takes care about the requested I-Frame. My first test was to create one index files for all ts files. To detect which ts contains the requested bytes i calc the file based on the filesize. I'm not sure if there is a better and also performance way to detect the correct file. Has anybody already done a rtsp streaming client with trickplay which can handle multiFileSources? Best regards Patrick From finlayson at live555.com Sun Apr 28 00:30:40 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Apr 2013 00:30:40 -0700 Subject: [Live-devel] trickplay with MultiFileSources In-Reply-To: <517CBF33.8060303@patrick-fischer.de> References: <51783AB7.6090303@gmx.de> <517CBF33.8060303@patrick-fischer.de> Message-ID: The index file mechanism simply wasn't designed to work with multiple files. It might be possible to hack it to do so, but your simplest solution would be to just create a single Transport Stream file by concatenating together your multiple files, and then creating an index file from (and then streaming) just the single Transport Stream file. These days, disk space is dirt cheap, and our software (and all modern OSs) will handle files > 2^32 bytes in size. So you should just do that. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zili.zhou at alcatel-lucent.com Sun Apr 28 01:37:44 2013 From: zili.zhou at alcatel-lucent.com (ZHOU, Zili (Zili)** CTR **) Date: Sun, 28 Apr 2013 10:37:44 +0200 Subject: [Live-devel] If there any Source classes can receive AAC stream from RTP over UDP Message-ID: <847511671F54DE4993965CCD25F38AE3674732623A@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Ross, As testOnDemandRTSPServer.cpp demonstrates, A MPEG2TS stream can be received directly from RTP over UDP. I want to know if an AAC stream( an ADTS format stream ) can be received directly as well. Or must I implement a subclass of FramedSource? Regards, Zili Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Apr 28 01:44:16 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Apr 2013 01:44:16 -0700 Subject: [Live-devel] If there any Source classes can receive AAC stream from RTP over UDP In-Reply-To: <847511671F54DE4993965CCD25F38AE3674732623A@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> References: <847511671F54DE4993965CCD25F38AE3674732623A@FRMRSSXCHMBSA1X.dc-m.alcatel-lucent.com> Message-ID: <0D20E4C2-0A2B-494C-9C70-03C0D895AD8E@live555.com> > I want to know if an AAC stream( an ADTS format stream ) can be received directly as well. Yes - using a "MPEG4GenericRTPSource" Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Sun Apr 28 04:24:34 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Sun, 28 Apr 2013 11:24:34 +0000 Subject: [Live-devel] testRTSPClient / H.264 Network Camera Stream In-Reply-To: <1ED2F9A76678E0428E90FB2B6F93672D010EA578@postal.sonicfoundry.net> References: <83B9617CAE5B45F9A1F79D52ECF9F25D@tbxpnotebook> <116624BF-DC40-4FA8-B616-C1C07B6F6827@live555.com> <4C7948BD431B4B909F8938F2D397B6E5@tbxpnotebook> <80C795F72B3CB241A9256DABF0A04EC53BB1CA4B@CH1PRD0710MB391.namprd07.prod.outlook.com>, <1ED2F9A76678E0428E90FB2B6F93672D010EA578@postal.sonicfoundry.net> Message-ID: <615FD77639372542BF647F5EBAA2DBC22530BD7F@IL-BOL-EXCH01.smartwire.com> I have solved this in my code by cacheing and inserting into the stream (using a filter). The decoder always needs it and, as stated, some encoders do not(axis default,pelco), some do(gvi,samsung) and some it is a setting(axis) ________________________________ From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] on behalf of Markus Schumann [markuss at sonicfoundry.com] Sent: Friday, April 26, 2013 3:02 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream I decode H.264 from a network camera. My decoder wants SPS/PPS once before the first I-frame in band delivered. So I wait until I get the first I-frame and then insert 0x0000001/SPS/0x0000001/PPS before the I-frame. Interestingly - one of the cameras I test with sends SPS/PPS inside the RTP stream ? I drop those SPS/PPSs. But you are right ? it?s decoder dependent. Markus. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremiah Morrill Sent: Friday, April 26, 2013 2:23 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient / H.264 Network Camera Stream After you parse the nal records from parseSPropParameterSets, store them. For each sample that comes through, construct the buffer you send to your upstream decoder like this: Where start_code is 4 bytes 0x00, 0x00, 0x00, 0x01 [start_code][NAL_record_1][start_code][NAL_record_2][start_code][sample_data] There may be some more correct way, but this has worked for me. Also some h264 decoders are different in how they except NAL units, so you may want to check with the documentation. -Jer This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at patrick-fischer.de Sun Apr 28 12:48:40 2013 From: info at patrick-fischer.de (Patrick Fischer) Date: Sun, 28 Apr 2013 21:48:40 +0200 Subject: [Live-devel] trickplay with MultiFileSources In-Reply-To: References: <51783AB7.6090303@gmx.de> <517CBF33.8060303@patrick-fischer.de> Message-ID: <517D7D18.2000108@patrick-fischer.de> Thanks. I have done some hacks but i have some problems with my hack. If i understand the index file right the file will only contains framecount and byteoffset. Frame -> Byte offset So my first solution if the requested byte is higher then the filesize of the first ByteStreamMultiFileSource, i will take the next ByteStreamFileSource. Regards Patrick Am 28.04.2013 09:30, schrieb Ross Finlayson: > The index file mechanism simply wasn't designed to work with multiple > files. It might be possible to hack it to do so, but your simplest > solution would be to just create a single Transport Stream file by > concatenating together your multiple files, and then creating an index > file from (and then streaming) just the single Transport Stream file. > These days, disk space is dirt cheap, and our software (and all > modern OSs) will handle files > 2^32 bytes in size. So you should > just do that. > > 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 smith at cognitec.com Mon Apr 29 04:05:43 2013 From: smith at cognitec.com (Robert Smith) Date: Mon, 29 Apr 2013 13:05:43 +0200 Subject: [Live-devel] Object Ownership in liveMedia Message-ID: <517E5407.2090104@cognitec.com> Hi Ross, Do you have any guidelines or conventions regarding object ownership in the library? For instance, when I create a PassiveServerMediaSubsession with an RTCPInstance*, I need to manually delete the RTCPInstance object myself. But when I create an H264VideoStreamFramer object with a FramedSource*, the Framer object cleans up the FramesSource object in it's destructor. Regards, Robert Smith From finlayson at live555.com Mon Apr 29 06:44:10 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Apr 2013 06:44:10 -0700 Subject: [Live-devel] Object Ownership in liveMedia In-Reply-To: <517E5407.2090104@cognitec.com> References: <517E5407.2090104@cognitec.com> Message-ID: <09989D24-A402-468F-86F1-FAD9C281BC8F@live555.com> > Do you have any guidelines or conventions regarding object ownership in the library? In general, the entity that create an object is responsible for deleting it. There are exceptions to this, though. For example - as you noted - when you have a 'chain' of "FramedSource" objects, feeding into each other (e.g., "source1"->"source(filter)2"->"source(filter)3"), then you delete them by deleting the tail object only. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From conchi.ap at vaelsys.com Mon Apr 29 06:58:49 2013 From: conchi.ap at vaelsys.com (Conchi Abasolo) Date: Mon, 29 Apr 2013 15:58:49 +0200 Subject: [Live-devel] Segmentation fault after TEARDOWN Message-ID: Hello, I've update to the last version of the live555 library (2013.04.23) and 've experiencing a problem that doesn't appear in previous versions. After a TEARDOWN sent by the client, the software crashes with a segmentation fault. I've reproduced the problem with the live555ProxyServer (I send attached the application log).You can see that after a TEARDOWN sent by the client, the proxy server tries to execute the "ProxyServerMediaSubsession["H264"]::closeStreamSource()", and then the segmentation fault occurs. I don't know whats happening, but with the 2013.04.01 version doesn't happen. It seems that any change in the last version causes this issue I would be grateful if someone could help me with this Conchi Abasolo P?rez C/Santiago Grisol?a n? 2, of. 203 Edif. PCM, Parque Tecnol?gico de Madrid 28760 Tres Cantos, Madrid -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ./live555ProxyServer -V -T 8081 rtsp://root:tis at 10.138.225.217/axis-media/media.amp LIVE555 Proxy Server (LIVE555 Streaming Media library version 2013.04.23) Opening connection to 10.138.225.217, port 8081... RTSP stream, proxying the stream "rtsp://root:tis at 10.138.225.217/axis-media/media.amp" Play this stream using the URL: rtsp://192.168.0.18:8554/proxyStream (We use port 8000 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Requesting RTSP-over-HTTP tunneling (on port 8081) Sending request: GET /axis-media/media.amp HTTP/1.0 CSeq: 1 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) x-sessioncookie: 3174648b9f95921fc4c2b4d Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Received 543 new bytes of response data. Received a complete GET response: HTTP/1.0 401 Unauthorized Date: Mon, 29 Apr 2013 13:40:58 GMT Accept-Ranges: bytes Connection: close WWW-Authenticate: Digest realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", stale=FALSE, qop="auth" WWW-Authenticate: Basic realm="AXIS_00408CD69DCC" Content-Length: 186 Content-Type: text/html; charset=ISO-8859-1 401 Unauthorized

401 Unauthorized

Your client does not have permission to get URL /axis-media/media.amp from this server. Resending... Opening connection to 10.138.225.217, port 8081... ...remote connection opened Sending request: GET /axis-media/media.amp HTTP/1.0 CSeq: 1 Authorization: Digest username="root", realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", uri="rtsp://root:tis at 10.138.225.217/axis-media/media.amp", response="c3c8d26a974b9dd8dd8e23590743a63d" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) x-sessioncookie: ec5473b608c3cfc9b3b8e33 Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Received 100 new bytes of response data. Received a complete GET response: HTTP/1.0 200 OK Content-Type: application/x-rtsp-tunnelled Date: Mon, 29 Apr 2013 13:41:03 GMT Opening connection to 10.138.225.217, port 8081... ...remote connection opened Sending request: POST /axis-media/media.amp HTTP/1.0 CSeq: 1 Authorization: Digest username="root", realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", uri="rtsp://root:tis at 10.138.225.217/axis-media/media.amp", response="f9dc25fa8a3b917b4bd5771fda6e6133" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) x-sessioncookie: ec5473b608c3cfc9b3b8e33 Content-Type: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Content-Length: 32767 Expires: Sun, 9 Jan 1972 00:00:00 GMT Sending request: DESCRIBE rtsp://root:tis at 10.138.225.217/axis-media/media.amp RTSP/1.0 CSeq: 2 Authorization: Digest username="root", realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", uri="rtsp://root:tis at 10.138.225.217/axis-media/media.amp", response="c10b25de8ccf771893908657722228b1" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) Accept: application/sdp The request was base-64 encoded to: REVTQ1JJQkUgcnRzcDovL3Jvb3Q6dGlzQDEwLjEzOC4yMjUuMjE3L2F4aXMtbWVkaWEvbWVkaWEuYW1wIFJUU1AvMS4wDQpDU2VxOiAyDQpBdXRob3JpemF0aW9uOiBEaWdlc3QgdXNlcm5hbWU9InJvb3QiLCByZWFsbT0iQVhJU18wMDQwOENENjlEQ0MiLCBub25jZT0iMDAwMDAxMDBZMzYzODcyYWYxZmQ0ZTE1MDkxODNmYTUzZTFjMzA0NDcwYmYyMyIsIHVyaT0icnRzcDovL3Jvb3Q6dGlzQDEwLjEzOC4yMjUuMjE3L2F4aXMtbWVkaWEvbWVkaWEuYW1wIiwgcmVzcG9uc2U9ImMxMGIyNWRlOGNjZjc3MTg5MzkwODY1NzcyMjIyOGIxIg0KVXNlci1BZ2VudDogUHJveHlSVFNQQ2xpZW50IChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxMy4wNC4yMykNCkFjY2VwdDogYXBwbGljYXRpb24vc2RwDQoNCg== Received 593 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Content-Type: application/sdp Content-Base: rtsp://10.138.225.217/axis-media/media.amp/ Date: Mon, 29 Apr 2013 13:41:13 GMT Content-Length: 417 v=0 o=- 1367242873678395 1367242873678395 IN IP4 10.138.225.217 s=Media Presentation e=NONE c=IN IP4 0.0.0.0 b=AS:50000 t=0 0 a=control:* a=range:npt=0.000000- m=video 0 RTP/AVP 96 b=AS:50000 a=framerate:2.0 a=transform:1,0,0;0,1,0;0,0,1 a=control:trackID=1 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; profile-level-id=420029; sprop-parameter-sets=Z0IAKeKQFgS3/gAYACycFAQXh4kRUA==,aM48gA== ProxyServerMediaSession["rtsp://10.138.225.217/axis-media/media.amp/"] added new "ProxyServerMediaSubsession" for RTP/video/H264 track accept()ed connection from 192.168.0.18 RTSPClientConnection[0x9491bd8]::handleRequestBytes() read 130 new bytes:OPTIONS rtsp://192.168.0.18:8554/proxyStream RTSP/1.0 CSeq: 1 User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "proxyStream", CSeq "1", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 1 Date: Mon, Apr 29 2013 13:41:52 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER RTSPClientConnection[0x9491bd8]::handleRequestBytes() read 156 new bytes:DESCRIBE rtsp://192.168.0.18:8554/proxyStream RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "proxyStream", CSeq "2", Content-Length 0, with 0 bytes following the message. ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() sending response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Apr 29 2013 13:41:52 GMT Content-Base: rtsp://192.168.0.18:8554/proxyStream/ Content-Type: application/sdp Content-Length: 544 v=0 o=- 1367242875799710 1 IN IP4 192.168.0.18 s=LIVE555 Streaming Media v2013.04.23 i=LIVE555 Streaming Media v2013.04.23 t=0 0 a=tool:LIVE555 Streaming Media v2013.04.23 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.04.23 a=x-qt-text-inf:LIVE555 Streaming Media v2013.04.23 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=Z0IAKeKQFgS3/gAYACycFAQXh4kRUA==,aM48gA== a=control:track1 RTSPClientConnection[0x9491bd8]::handleRequestBytes() read 187 new bytes:SETUP rtsp://192.168.0.18:8554/proxyStream/track1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=42890-42891 User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "proxyStream", urlSuffix "track1", CSeq "3", Content-Length 0, with 0 bytes following the message. ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 3606645743) Sending request: SETUP rtsp://10.138.225.217/axis-media/media.amp/trackID=1 RTSP/1.0 CSeq: 3 Authorization: Digest username="root", realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", uri="rtsp://10.138.225.217/axis-media/media.amp/", response="0f0054208f2d39bd1a24305008c5633c" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 The request was base-64 encoded to: U0VUVVAgcnRzcDovLzEwLjEzOC4yMjUuMjE3L2F4aXMtbWVkaWEvbWVkaWEuYW1wL3RyYWNrSUQ9MSBSVFNQLzEuMA0KQ1NlcTogMw0KQXV0aG9yaXphdGlvbjogRGlnZXN0IHVzZXJuYW1lPSJyb290IiwgcmVhbG09IkFYSVNfMDA0MDhDRDY5RENDIiwgbm9uY2U9IjAwMDAwMTAwWTM2Mzg3MmFmMWZkNGUxNTA5MTgzZmE1M2UxYzMwNDQ3MGJmMjMiLCB1cmk9InJ0c3A6Ly8xMC4xMzguMjI1LjIxNy9heGlzLW1lZGlhL21lZGlhLmFtcC8iLCByZXNwb25zZT0iMGYwMDU0MjA4ZjJkMzliZDFhMjQzMDUwMDhjNTYzM2MiDQpVc2VyLUFnZW50OiBQcm94eVJUU1BDbGllbnQgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDEzLjA0LjIzKQ0KVHJhbnNwb3J0OiBSVFAvQVZQL1RDUDt1bmljYXN0O2ludGVybGVhdmVkPTAtMQ0KDQo= ProxyServerMediaSubsession["H264"]::createNewRTPSink() sending response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Apr 29 2013 13:41:52 GMT Transport: RTP/AVP;unicast;destination=192.168.0.18;source=192.168.0.18;client_port=42890-42891;server_port=6970-6971 Session: D6F90BEF RTSPClientConnection[0x9491bd8]::handleRequestBytes() read 166 new bytes:PLAY rtsp://192.168.0.18:8554/proxyStream/ RTSP/1.0 CSeq: 4 Session: D6F90BEF Range: npt=0.000- User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "proxyStream", urlSuffix "", CSeq "4", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Apr 29 2013 13:41:52 GMT Range: npt=0.000- Session: D6F90BEF RTP-Info: url=rtsp://192.168.0.18:8554/proxyStream/track1;seq=40427;rtptime=2507635495 RTSPClientConnection[0x9491bd8]::handleRequestBytes() read 156 new bytes:GET_PARAMETER rtsp://192.168.0.18:8554/proxyStream/ RTSP/1.0 CSeq: 5 Session: D6F90BEF User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "proxyStream", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 5 Date: Mon, Apr 29 2013 13:41:52 GMT Session: D6F90BEF Content-Length: 10 2013.04.23RTSP client session (id "D6F90BEF", stream name "proxyStream"): Liveness indication Received 170 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Session: EEEF3EFF; timeout=60 Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=2DCF666E;mode="PLAY" Date: Mon, 29 Apr 2013 13:41:33 GMT ProxyRTSPClient["rtsp://10.138.225.217/axis-media/media.amp/"]::continueAfterSETUP(): head codec: H264; numSubsessions 1 queue: H264 Sending request: PLAY rtsp://10.138.225.217/axis-media/media.amp/ RTSP/1.0 CSeq: 4 Authorization: Digest username="root", realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", uri="rtsp://10.138.225.217/axis-media/media.amp/", response="3db8ce1016528218e86164c4fa939546" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) Session: EEEF3EFF The request was base-64 encoded to: UExBWSBydHNwOi8vMTAuMTM4LjIyNS4yMTcvYXhpcy1tZWRpYS9tZWRpYS5hbXAvIFJUU1AvMS4wDQpDU2VxOiA0DQpBdXRob3JpemF0aW9uOiBEaWdlc3QgdXNlcm5hbWU9InJvb3QiLCByZWFsbT0iQVhJU18wMDQwOENENjlEQ0MiLCBub25jZT0iMDAwMDAxMDBZMzYzODcyYWYxZmQ0ZTE1MDkxODNmYTUzZTFjMzA0NDcwYmYyMyIsIHVyaT0icnRzcDovLzEwLjEzOC4yMjUuMjE3L2F4aXMtbWVkaWEvbWVkaWEuYW1wLyIsIHJlc3BvbnNlPSIzZGI4Y2UxMDE2NTI4MjE4ZTg2MTY0YzRmYTkzOTU0NiINClVzZXItQWdlbnQ6IFByb3h5UlRTUENsaWVudCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTMuMDQuMjMpDQpTZXNzaW9uOiBFRUVGM0VGRg0KDQo= RTSP client session (id "D6F90BEF", stream name "proxyStream"): Liveness indication Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Session: EEEF3EFF Range: npt=0- RTP-Info: url=rtsp://10.138.225.217/axis-media/media.amp/trackID=1;seq=48946;rtptime=2154482277 Date: Mon, 29 Apr 2013 13:41:39 GMT RTSPClientConnection[0x9491bd8]::handleRequestBytes() read 151 new bytes:TEARDOWN rtsp://192.168.0.18:8554/proxyStream/ RTSP/1.0 CSeq: 6 Session: D6F90BEF User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix "proxyStream", urlSuffix "", CSeq "6", Content-Length 0, with 0 bytes following the message. ProxyServerMediaSubsession["H264"]::closeStreamSource() Sending request: PAUSE rtsp://10.138.225.217/axis-media/media.amp/ RTSP/1.0 CSeq: 5 Authorization: Digest username="root", realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", uri="rtsp://10.138.225.217/axis-media/media.amp/", response="9945860803683801a6eac8620cfb9398" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) Session: EEEF3EFF The request was base-64 encoded to: UEFVU0UgcnRzcDovLzEwLjEzOC4yMjUuMjE3L2F4aXMtbWVkaWEvbWVkaWEuYW1wLyBSVFNQLzEuMA0KQ1NlcTogNQ0KQXV0aG9yaXphdGlvbjogRGlnZXN0IHVzZXJuYW1lPSJyb290IiwgcmVhbG09IkFYSVNfMDA0MDhDRDY5RENDIiwgbm9uY2U9IjAwMDAwMTAwWTM2Mzg3MmFmMWZkNGUxNTA5MTgzZmE1M2UxYzMwNDQ3MGJmMjMiLCB1cmk9InJ0c3A6Ly8xMC4xMzguMjI1LjIxNy9heGlzLW1lZGlhL21lZGlhLmFtcC8iLCByZXNwb25zZT0iOTk0NTg2MDgwMzY4MzgwMWE2ZWFjODYyMGNmYjkzOTgiDQpVc2VyLUFnZW50OiBQcm94eVJUU1BDbGllbnQgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDEzLjA0LjIzKQ0KU2Vzc2lvbjogRUVFRjNFRkYNCg0K sending response: RTSP/1.0 200 OK CSeq: 6 Date: Mon, Apr 29 2013 13:42:03 GMT RTSPClientConnection[0x9491bd8]::handleRequestBytes() read -1 new bytes (of 10000); terminating connection! accept()ed connection from 192.168.0.18 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 130 new bytes:OPTIONS rtsp://192.168.0.18:8554/proxyStream RTSP/1.0 CSeq: 1 User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "proxyStream", CSeq "1", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 1 Date: Mon, Apr 29 2013 13:42:03 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 156 new bytes:DESCRIBE rtsp://192.168.0.18:8554/proxyStream RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "proxyStream", CSeq "2", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Apr 29 2013 13:42:03 GMT Content-Base: rtsp://192.168.0.18:8554/proxyStream/ Content-Type: application/sdp Content-Length: 544 v=0 o=- 1367242875799710 1 IN IP4 192.168.0.18 s=LIVE555 Streaming Media v2013.04.23 i=LIVE555 Streaming Media v2013.04.23 t=0 0 a=tool:LIVE555 Streaming Media v2013.04.23 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.04.23 a=x-qt-text-inf:LIVE555 Streaming Media v2013.04.23 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=Z0IAKeKQFgS3/gAYACycFAQXh4kRUA==,aM48gA== a=control:track1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 183 new bytes:SETUP rtsp://192.168.0.18:8554/proxyStream/track1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "proxyStream", urlSuffix "track1", CSeq "3", Content-Length 0, with 0 bytes following the message. ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 1639518717) Sending request: PLAY rtsp://10.138.225.217/axis-media/media.amp/ RTSP/1.0 CSeq: 6 Authorization: Digest username="root", realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", uri="rtsp://10.138.225.217/axis-media/media.amp/", response="3db8ce1016528218e86164c4fa939546" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) Session: EEEF3EFF The request was base-64 encoded to: UExBWSBydHNwOi8vMTAuMTM4LjIyNS4yMTcvYXhpcy1tZWRpYS9tZWRpYS5hbXAvIFJUU1AvMS4wDQpDU2VxOiA2DQpBdXRob3JpemF0aW9uOiBEaWdlc3QgdXNlcm5hbWU9InJvb3QiLCByZWFsbT0iQVhJU18wMDQwOENENjlEQ0MiLCBub25jZT0iMDAwMDAxMDBZMzYzODcyYWYxZmQ0ZTE1MDkxODNmYTUzZTFjMzA0NDcwYmYyMyIsIHVyaT0icnRzcDovLzEwLjEzOC4yMjUuMjE3L2F4aXMtbWVkaWEvbWVkaWEuYW1wLyIsIHJlc3BvbnNlPSIzZGI4Y2UxMDE2NTI4MjE4ZTg2MTY0YzRmYTkzOTU0NiINClVzZXItQWdlbnQ6IFByb3h5UlRTUENsaWVudCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTMuMDQuMjMpDQpTZXNzaW9uOiBFRUVGM0VGRg0KDQo= ProxyServerMediaSubsession["H264"]::createNewRTPSink() sending response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Apr 29 2013 13:42:03 GMT Transport: RTP/AVP/TCP;unicast;destination=192.168.0.18;source=192.168.0.18;interleaved=0-1 Session: 61B911FD RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 166 new bytes:PLAY rtsp://192.168.0.18:8554/proxyStream/ RTSP/1.0 CSeq: 4 Session: 61B911FD Range: npt=0.000- User-Agent: LibVLC/1.1.3 (LIVE555 Streaming Media v2010.04.09) parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "proxyStream", urlSuffix "", CSeq "4", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Apr 29 2013 13:42:03 GMT Range: npt=0.000- Session: 61B911FD RTP-Info: url=rtsp://192.168.0.18:8554/proxyStream/track1;seq=63480;rtptime=2878041611 RTSP client session (id "61B911FD", stream name "proxyStream"): Liveness indication Received a complete PAUSE response: RTSP/1.0 200 OK CSeq: 5 Session: EEEF3EFF Date: Mon, 29 Apr 2013 13:41:44 GMT RTSP client session (id "61B911FD", stream name "proxyStream"): Liveness indication RTSP client session (id "61B911FD", stream name "proxyStream"): Liveness indication RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:T RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:E RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:A RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:R RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:D RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:O RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:W RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:N RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:t RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:s RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:p RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:9 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:2 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:6 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:8 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:8 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:8 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:4 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:p RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:o RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:x RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:y RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:t RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:a RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:m RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:R RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:T RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:P RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:C RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:q RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:s RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:s RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:i RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:o RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:n RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:6 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:B RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:9 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:F RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:D RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:U RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:s RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:- RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:A RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:g RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:n RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:t RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:L RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:i RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:b RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:V RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:L RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:C RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:/ RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:3 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:( RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:L RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:I RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:V RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:E RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:5 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:S RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:t RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:r RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:a RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:m RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:i RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:n RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:g RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:M RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:e RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:d RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:i RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:a RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:v RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:2 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:1 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:4 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:. RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:0 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:9 RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes:) RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: RTSPClientConnection[0x9491bb0]::handleRequestBytes() read 1 new bytes: parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix "proxyStream", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the message. ProxyServerMediaSubsession["H264"]::closeStreamSource() Sending request: PAUSE rtsp://10.138.225.217/axis-media/media.amp/ RTSP/1.0 CSeq: 7 Authorization: Digest username="root", realm="AXIS_00408CD69DCC", nonce="00000100Y363872af1fd4e1509183fa53e1c304470bf23", uri="rtsp://10.138.225.217/axis-media/media.amp/", response="9945860803683801a6eac8620cfb9398" User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.04.23) Session: EEEF3EFF The request was base-64 encoded to: UEFVU0UgcnRzcDovLzEwLjEzOC4yMjUuMjE3L2F4aXMtbWVkaWEvbWVkaWEuYW1wLyBSVFNQLzEuMA0KQ1NlcTogNw0KQXV0aG9yaXphdGlvbjogRGlnZXN0IHVzZXJuYW1lPSJyb290IiwgcmVhbG09IkFYSVNfMDA0MDhDRDY5RENDIiwgbm9uY2U9IjAwMDAwMTAwWTM2Mzg3MmFmMWZkNGUxNTA5MTgzZmE1M2UxYzMwNDQ3MGJmMjMiLCB1cmk9InJ0c3A6Ly8xMC4xMzguMjI1LjIxNy9heGlzLW1lZGlhL21lZGlhLmFtcC8iLCByZXNwb25zZT0iOTk0NTg2MDgwMzY4MzgwMWE2ZWFjODYyMGNmYjkzOTgiDQpVc2VyLUFnZW50OiBQcm94eVJUU1BDbGllbnQgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDEzLjA0LjIzKQ0KU2Vzc2lvbjogRUVFRjNFRkYNCg0K sending response: RTSP/1.0 200 OK CSeq: 5 Date: Mon, Apr 29 2013 13:42:20 GMT Violaci?n de segmento From finlayson at live555.com Mon Apr 29 07:24:08 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Apr 2013 07:24:08 -0700 Subject: [Live-devel] Segmentation fault after TEARDOWN In-Reply-To: References: Message-ID: <14B025ED-EDF8-47A5-98C9-20B386260C81@live555.com> Sorry, but right now I can't reproduce this. Could you please post a stack trace from the point of the crash? Also, to help track down what might be going wrong: 1/ Does the crash happen even with an up-to-date version of VLC (rather than one that's more than 3 years old)? 2/ Does the crash happen even when the proxy server accesses its 'back end' stream using regular RTSP, or does it occur only when the proxy server access its 'back end' stream using RTSP-over-HTTP? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From RUSSELL.A.TYSON.III at saic.com Mon Apr 29 08:01:54 2013 From: RUSSELL.A.TYSON.III at saic.com (Tyson, Russell A. III) Date: Mon, 29 Apr 2013 08:01:54 -0700 Subject: [Live-devel] RTSPClient WRT connection to rtsp server (camera) Message-ID: <2B46BE148DC68D4DAF4347964A0A2517038CFD82@0461-its-exmb06.us.saic.com> First, I want to thank you for the great library! I appreciate your hard work on this! I am somewhat new to Live555, and to the world of video processing, so bear with me if I ask some silly questions. I am working on a windows service (a "Manager") that starts, monitors, and stops multiple Proxy servers. These proxy servers are based on your Live555 Proxy Server code. Each proxy is serving a single stream from a single back end camera. This manager is written in managed C#, obviously the proxies are in unmanaged C++. This system runs with no user intervention outside of starting various clients to view the streaming video. This "Manager" service is responsible for starting each proxy with a given back end rtsp address, monitoring the state of the proxies, and shutting any or all proxies down when directed, or when the proxy's state becomes unstable. The manager reports its state (which is the state of all proxies) to other services in our application. During the lifetime of the proxy, I expect that the back end connection could terminate for some reason, or not connect at all in the first place. I have been looking for a hook to report this state back to the manager, but have not been successful. Does the RTSPClient provide any type of event, or other signal that could be used by other processes/services for the purpose of monitoring the state of the back end connection? My apologies if I have overlooked it in my search. Now for part 2... In our system, we also have an archiving service. This service connects to the stream provided by the proxy and archives the data to a file. One archiver exists for each proxy. The Archiver uses the OpenRTSP client to achieve this. I have noticed that if the OpenRTSP client terminates unexpectedly, the CPU usage of the proxy skyrockets from about .07 average up to around 22.5 average. We run about 25 of the proxies, so you can imagine the hit if 4 of these clients die. In the case where the archiving service as a whole dies, all of the clients can terminate, which leaves us with 25 proxies running at around a 22% CPU usage with makes the system unusable. I had considered monitoring the CPU load on all of the proxies through the manager, and terminating/restarting any that run high on CPU usage. But I was wondering if you could shed some light on what is going on in the proxy to produce this effect. Thanks in advance! Russell Tyson | SAIC Senior Software Engineer | Software Solutions Team phone: 256-971-6640 | mobile: 256-651-9981 russell.a.tyson.iii at saic.com | saic.com Science Applications International Corporation 6723 Odyssey Drive NW Huntsville, AL 35806 NATIONAL SECURITY | ENERGY & ENVIRONMENT | HEALTH | CYBERSECURITY This email and any attachments to it are intended only for the identified recipients. It may contain proprietary or otherwise legally protected information of SAIC. Any unauthorized use or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete or otherwise destroy the email and all attachments immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Serge.Grondin at miranda.com Mon Apr 29 12:14:16 2013 From: Serge.Grondin at miranda.com (Serge.Grondin at miranda.com) Date: Mon, 29 Apr 2013 15:14:16 -0400 Subject: [Live-devel] Segmentation fault after TEARDOWN In-Reply-To: References: Message-ID: Hi guys, I got the exact same crash today while testing RTSP over TCP, I can see that the root cause seems to come from file RTPInterface.cpp in SocketDescriptor::tcpReadHandler() (line 406). There is a while loop that was not there before and it finally crash in Groupsock while looping this code. I don't have time now to give more info but I can provider a better call stack later if needed. Serge From: Conchi Abasolo To: live-devel at ns.live555.com, Date: 2013-04-29 10:04 Subject: [Live-devel] Segmentation fault after TEARDOWN Sent by: live-devel-bounces at ns.live555.com Hello, I've update to the last version of the live555 library (2013.04.23) and 've experiencing a problem that doesn't appear in previous versions. After a TEARDOWN sent by the client, the software crashes with a segmentation fault. I've reproduced the problem with the live555ProxyServer (I send attached the application log).You can see that after a TEARDOWN sent by the client, the proxy server tries to execute the "ProxyServerMediaSubsession ["H264"]::closeStreamSource()", and then the segmentation fault occurs. I don't know whats happening, but with the 2013.04.01 version doesn't happen. It seems that any change in the last version causes this issue I would be grateful if someone could help me with this Conchi Abasolo P?rez C/Santiago Grisol?a n? 2, of. 203 Edif. PCM, Parque Tecnol?gico de Madrid 28760 Tres Cantos, Madrid [attachment "live555ProxyServer.txt" deleted by Serge Grondin/MontrealMIR/BeldenCDT] _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From finlayson at live555.com Mon Apr 29 12:29:26 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Apr 2013 12:29:26 -0700 Subject: [Live-devel] RTSPClient WRT connection to rtsp server (camera) In-Reply-To: <2B46BE148DC68D4DAF4347964A0A2517038CFD82@0461-its-exmb06.us.saic.com> References: <2B46BE148DC68D4DAF4347964A0A2517038CFD82@0461-its-exmb06.us.saic.com> Message-ID: <848EBD2A-0A06-4854-AB41-7413BBF6637B@live555.com> > I am working on a windows service (a ?Manager?) that starts, monitors, and stops multiple Proxy servers. These proxy servers are based on your Live555 Proxy Server code. Each proxy is serving a single stream from a single back end camera. Note that you don't have to do that. It's possible for a single proxy server to serve multiple 'back end' streams. (E.g., our "LIVE555 Proxy Server" application can do this.) > During the lifetime of the proxy, I expect that the back end connection could terminate for some reason, or not connect at all in the first place. I have been looking for a hook to report this state back to the manager, but have not been successful. Does the RTSPClient provide any type of event, or other signal that could be used by other processes/services for the purpose of monitoring the state of the back end connection? Note that our proxy server code already monitors and keeps alive the connection to each of its 'back end' server. This is not something that you need to handle separately. > In our system, we also have an archiving service. This service connects to the stream provided by the proxy and archives the data to a file. One archiver exists for each proxy. The Archiver uses the OpenRTSP client to achieve this. I have noticed that if the OpenRTSP client terminates unexpectedly, the CPU usage of the proxy skyrockets from about .07 average up to around 22.5 average. We run about 25 of the proxies, so you can imagine the hit if 4 of these clients die. In the case where the archiving service as a whole dies, all of the clients can terminate, which leaves us with 25 proxies running at around a 22% CPU usage with makes the system unusable. > > I had considered monitoring the CPU load on all of the proxies through the manager, and terminating/restarting any that run high on CPU usage. But I was wondering if you could shed some light on what is going on in the proxy to produce this effect. Sorry - no idea. That's something that you're going to have to track down yourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Mon Apr 29 12:52:30 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Mon, 29 Apr 2013 19:52:30 +0000 Subject: [Live-devel] Segmentation fault after TEARDOWN In-Reply-To: References: Message-ID: I unfortunately don't have much more info, but I believe I also experience this issue. Last week I upgraded from 2013.03.07 to 2013.04.23 and we suddenly started to experience program crashes (liveMedia used within a DLL in Windows client streaming mjpeg). I didn't suspect the liveMedia update at first, since we also had made some other changes, but when I saw your message I reverted back to 2013.03.07 and now everything seems to work as before. /Claes From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Serge.Grondin at miranda.com Sent: Monday, April 29, 2013 2:14 PM To: LIVE555 Streaming Media - development & use Cc: live-devel-bounces at ns.live555.com Subject: Re: [Live-devel] Segmentation fault after TEARDOWN Hi guys, I got the exact same crash today while testing RTSP over TCP, I can see that the root cause seems to come from file RTPInterface.cpp in SocketDescriptor::tcpReadHandler() (line 406). There is a while loop that was not there before and it finally crash in Groupsock while looping this code. I don't have time now to give more info but I can provider a better call stack later if needed. Serge Inactive hide details for Conchi Abasolo ---2013-04-29 10:04:46---Hello, I've update to the last version of the live555 libraryConchi Abasolo ---2013-04-29 10:04:46---Hello, I've update to the last version of the live555 library (2013.04.23) and 've From: Conchi Abasolo To: live-devel at ns.live555.com, Date: 2013-04-29 10:04 Subject: [Live-devel] Segmentation fault after TEARDOWN Sent by: live-devel-bounces at ns.live555.com _____ Hello, I've update to the last version of the live555 library (2013.04.23) and 've experiencing a problem that doesn't appear in previous versions. After a TEARDOWN sent by the client, the software crashes with a segmentation fault. I've reproduced the problem with the live555ProxyServer (I send attached the application log).You can see that after a TEARDOWN sent by the client, the proxy server tries to execute the "ProxyServerMediaSubsession["H264"]::closeStreamSource()", and then the segmentation fault occurs. I don't know whats happening, but with the 2013.04.01 version doesn't happen. It seems that any change in the last version causes this issue I would be grateful if someone could help me with this Conchi Abasolo P?rez C/Santiago Grisol?a n? 2, of. 203 Edif. PCM, Parque Tecnol?gico de Madrid 28760 Tres Cantos, Madrid [attachment "live555ProxyServer.txt" deleted by Serge Grondin/MontrealMIR/BeldenCDT] _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: not available 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 RUSSELL.A.TYSON.III at saic.com Mon Apr 29 13:07:02 2013 From: RUSSELL.A.TYSON.III at saic.com (Tyson, Russell A. III) Date: Mon, 29 Apr 2013 13:07:02 -0700 Subject: [Live-devel] RTSPClient WRT connection to rtsp server (camera) In-Reply-To: <848EBD2A-0A06-4854-AB41-7413BBF6637B@live555.com> References: <2B46BE148DC68D4DAF4347964A0A2517038CFD82@0461-its-exmb06.us.saic.com> <848EBD2A-0A06-4854-AB41-7413BBF6637B@live555.com> Message-ID: <2B46BE148DC68D4DAF4347964A0A2517038CFF4B@0461-its-exmb06.us.saic.com> Thanks for your quick response Ross! Note that you don't have to do that. It's possible for a single proxy server to serve multiple 'back end' streams. (E.g., our "LIVE555 Proxy Server" application can do this.) Our approach with this one-to-one setup was to ensure that we didn't lose all of our camera streams if one proxy server crashed. This system is designed to run on its own for long periods of time (days, weeks, etc.) with minimal user interaction other than connecting clients (VLC) to view available streams. Note that our proxy server code already monitors and keeps alive the connection to each of its 'back end' server. This is not something that you need to handle separately. Yes, and we are relying on that code to reconnect to the camera. What I was looking for was a connection status event, if you will, so that my manager service can notify, or respond to queries from other services about the proxy/camera connection state. i.e. A GUI displays a list of available cameras to an end user. I would like to only list cameras that are currently connected to their respective proxy. If, for some reason, a proxy loses its connection to a camera, I would like to be able to exclude this particular camera from the list, or at least notify the "client" that it is not currently connected. This type of event could also be used to alert other services of a problem with the system if a camera/proxy connection suddenly goes down and is not restored by the proxy server in some period of time. Cheers! Russell Tyson | SAIC Senior Software Engineer | Software Solutions Team phone: 256-971-6640 | mobile: 256-651-9981 russell.a.tyson.iii at saic.com | saic.com From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, April 29, 2013 2:29 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTSPClient WRT connection to rtsp server (camera) I am working on a windows service (a "Manager") that starts, monitors, and stops multiple Proxy servers. These proxy servers are based on your Live555 Proxy Server code. Each proxy is serving a single stream from a single back end camera. Note that you don't have to do that. It's possible for a single proxy server to serve multiple 'back end' streams. (E.g., our "LIVE555 Proxy Server" application can do this.) During the lifetime of the proxy, I expect that the back end connection could terminate for some reason, or not connect at all in the first place. I have been looking for a hook to report this state back to the manager, but have not been successful. Does the RTSPClient provide any type of event, or other signal that could be used by other processes/services for the purpose of monitoring the state of the back end connection? Note that our proxy server code already monitors and keeps alive the connection to each of its 'back end' server. This is not something that you need to handle separately. In our system, we also have an archiving service. This service connects to the stream provided by the proxy and archives the data to a file. One archiver exists for each proxy. The Archiver uses the OpenRTSP client to achieve this. I have noticed that if the OpenRTSP client terminates unexpectedly, the CPU usage of the proxy skyrockets from about .07 average up to around 22.5 average. We run about 25 of the proxies, so you can imagine the hit if 4 of these clients die. In the case where the archiving service as a whole dies, all of the clients can terminate, which leaves us with 25 proxies running at around a 22% CPU usage with makes the system unusable. I had considered monitoring the CPU load on all of the proxies through the manager, and terminating/restarting any that run high on CPU usage. But I was wondering if you could shed some light on what is going on in the proxy to produce this effect. Sorry - no idea. That's something that you're going to have to track down yourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 29 13:34:00 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Apr 2013 13:34:00 -0700 Subject: [Live-devel] Segmentation fault after TEARDOWN In-Reply-To: References: Message-ID: OK, I have just installed a new version (2013.04.29) of the code that should - I think - fix this problem. (The problem was introduced in version 2013.04.21 when I added Colin Caughie's optimization for handling RTP-over-TCP channels. That optimization worked well, except that in some cases it could have caused a just-deleted structure to be accessed. This should now be fixed.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Apr 29 13:40:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Apr 2013 13:40:06 -0700 Subject: [Live-devel] RTSPClient WRT connection to rtsp server (camera) In-Reply-To: <2B46BE148DC68D4DAF4347964A0A2517038CFF4B@0461-its-exmb06.us.saic.com> References: <2B46BE148DC68D4DAF4347964A0A2517038CFD82@0461-its-exmb06.us.saic.com> <848EBD2A-0A06-4854-AB41-7413BBF6637B@live555.com> <2B46BE148DC68D4DAF4347964A0A2517038CFF4B@0461-its-exmb06.us.saic.com> Message-ID: <3E848DF1-119E-45BF-8606-C9C8F188E47F@live555.com> > Note that our proxy server code already monitors and keeps alive the connection to each of its 'back end' server. This is not something that you need to handle separately. > > Yes, and we are relying on that code to reconnect to the camera. What I was looking for was a connection status event Right now the only way to do this would be to parse the debugging output from the proxy server when you ask for 'verbose output' - i.e., if you give "live555ProxyServer" the -V option, or set "verbosityLevel" to 2 in the call to "ProxyServerMediaSession::createNew()". If you want to do something more sophisticated, then you'll need to write your own class - similar to "ProxyServerMediaSession" - that adds your own monitoring code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From RUSSELL.A.TYSON.III at saic.com Mon Apr 29 14:00:46 2013 From: RUSSELL.A.TYSON.III at saic.com (Tyson, Russell A. III) Date: Mon, 29 Apr 2013 14:00:46 -0700 Subject: [Live-devel] RTSPClient WRT connection to rtsp server (camera) In-Reply-To: <3E848DF1-119E-45BF-8606-C9C8F188E47F@live555.com> References: <2B46BE148DC68D4DAF4347964A0A2517038CFD82@0461-its-exmb06.us.saic.com> <848EBD2A-0A06-4854-AB41-7413BBF6637B@live555.com> <2B46BE148DC68D4DAF4347964A0A2517038CFF4B@0461-its-exmb06.us.saic.com> <3E848DF1-119E-45BF-8606-C9C8F188E47F@live555.com> Message-ID: <2B46BE148DC68D4DAF4347964A0A2517038CFF8C@0461-its-exmb06.us.saic.com> I'll start looking into setting that up. Thanks for the timely help! Russell Tyson | SAIC Senior Software Engineer | Software Solutions Team phone: 256-971-6640 | mobile: 256-651-9981 russell.a.tyson.iii at saic.com | saic.com From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, April 29, 2013 3:40 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTSPClient WRT connection to rtsp server (camera) Note that our proxy server code already monitors and keeps alive the connection to each of its 'back end' server. This is not something that you need to handle separately. Yes, and we are relying on that code to reconnect to the camera. What I was looking for was a connection status event Right now the only way to do this would be to parse the debugging output from the proxy server when you ask for 'verbose output' - i.e., if you give "live555ProxyServer" the -V option, or set "verbosityLevel" to 2 in the call to "ProxyServerMediaSession::createNew()". If you want to do something more sophisticated, then you'll need to write your own class - similar to "ProxyServerMediaSession" - that adds your own monitoring code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 30 09:05:20 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Apr 2013 09:05:20 -0700 Subject: [Live-devel] Announcing: LIVE555 Funded Projects Message-ID: <54137BF9-C385-4EBF-96AC-4F1846DCC7A6@live555.com> There is now a new way for people (and companies) to support new features in the "LIVE555 Streaming Media" software: "LIVE555 Funded Projects": http://live555.com/funded-projects/ Based on the results from the recent survey, two of the most voted-for new features - support for IPv6 and the support for writing MKV files - have been introduced as funded projects. More funded projects will be added in the future. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From megaplace at hotmail.com Tue Apr 30 14:47:17 2013 From: megaplace at hotmail.com (Krishna Patel) Date: Tue, 30 Apr 2013 21:47:17 +0000 Subject: [Live-devel] 2013.04.21 crash bug is not fixed Message-ID: Hi,Crash bug introduced in version 2013.04.21 is not fixed in 2013.04.29. Occasionally at session shutdown SocketDescriptor object still gets accessed after it was deleted. Version 2013.04.16 does not have such problem. Here's some info: Exception info:EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 00000000101041db (RTSPRec!SocketDescriptor::tcpReadHandler+0x000000000000008b) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000000 Parameter[1]: 00000000dddddddd Attempt to read from address 00000000dddddddd Crash stack:ChildEBP RetAddr Args to Child 03a3f65c 1012525e 0478fc10 00000002 88e18a61 RTSPRec!SocketDescriptor::tcpReadHandler+0x8b 03a3fa08 1012759b 00000000 03a3fa28 047838f8 RTSPRec!BasicTaskScheduler::SingleStep+0x72e 03a3fa1c 100ac67e 04783729 03a3fbe8 03a3fb0c RTSPRec!BasicTaskScheduler0::doEventLoop+0x3b 03a3fb04 100a82f8 88e18b91 03a3fcf4 0050ca04 RTSPRec!CRTSPHandler::ShutdownSession+0xae 03a3fbf8 100a1c6d 03a3fdf8 0050ca04 0050ca68 RTSPRec!CRTSPHandler::Uninit+0xa8 03a3fcf4 1009ffcf 20000000 0050ca04 0050ca68 RTSPRec!CRTSPReceiver::UninitRTSP+0x3d 03a3fdf8 672724fa 04782ff0 00000260 0050ce44 RTSPRec!CRTSPReceiver::Stop+0x6f SocketDescriptor::tcpReadHandler local members:0:022:x86> dv socketDescriptor = 0x0478fc10 mask = 0n2 count = 0x7d0 SocketDescriptor class members:0:022:x86> ?? socketDescriptor class SocketDescriptor * 0x0478fc10 +0x000 __VFN_table : 0xdddddddd +0x004 fEnv : 0xdddddddd UsageEnvironment +0x008 fOurSocketNum : 0n-572662307 +0x00c fSubChannelHashTable : 0xdddddddd HashTable +0x010 fServerRequestAlternativeByteHandler : 0xdddddddd void +ffffffffdddddddd +0x014 fServerRequestAlternativeByteHandlerClientData : 0xdddddddd Void +0x018 fStreamChannelId : 0xdd '' +0x019 fSizeByte1 : 0xdd '' +0x01a fReadErrorOccurred : ffffffffffffffdd +0x01b fDeleteNext : ffffffffffffffdd +0x01c fTCPReadingState : 0xdddddddd (No matching name) socketDescriptor is toast void SocketDescriptor::tcpReadHandler(SocketDescriptor* socketDescriptor, int mask) { // Call the read handler until it returns false, with a limit to avoid starving other sockets unsigned count = 2000; while (!socketDescriptor->fDeleteNext && socketDescriptor->tcpReadHandler1(mask) && --count > 0) {} if (socketDescriptor->fDeleteNext) delete socketDescriptor; <- Crash here } Krishna. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 30 15:18:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Apr 2013 15:18:36 -0700 Subject: [Live-devel] 2013.04.21 crash bug is not fixed In-Reply-To: References: Message-ID: <2D919182-9876-42A5-B6F9-9AB6AE6068AD@live555.com> > Crash bug introduced in version 2013.04.21 is not fixed in 2013.04.29. Thanks for the report. Please download a new version 2013.04.30 which, I hope, should fix this for real. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From megaplace at hotmail.com Tue Apr 30 17:05:07 2013 From: megaplace at hotmail.com (Krishna Patel) Date: Wed, 1 May 2013 00:05:07 +0000 Subject: [Live-devel] 2013.04.21 crash bug is not fixed In-Reply-To: <2D919182-9876-42A5-B6F9-9AB6AE6068AD@live555.com> References: , <2D919182-9876-42A5-B6F9-9AB6AE6068AD@live555.com> Message-ID: It's fixed. Thanks! From: finlayson at live555.com Date: Tue, 30 Apr 2013 15:18:36 -0700 To: live-devel at ns.live555.com Subject: Re: [Live-devel] 2013.04.21 crash bug is not fixed Crash bug introduced in version 2013.04.21 is not fixed in 2013.04.29. Thanks for the report. Please download a new version 2013.04.30 which, I hope, should fix this for real. 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: