From finlayson at live555.com Thu Aug 1 02:26:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Aug 2013 11:26:35 +0200 Subject: [Live-devel] Unable to set PPS/SPS headers In-Reply-To: <51EE4855.8080608@mindpower.pl> References: <51EE4855.8080608@mindpower.pl> Message-ID: > The problem is that my SPS/PPS NALs are never used in SDP. After some > debugging i reached the place where Session Description is created in > H264VideoRTPSink: > > if (sps == NULL || pps == NULL) { > // We need to get SPS and PPS from our framer source: > if (fOurFragmenter == NULL) return NULL; // we don't yet have a > fragmenter (and therefore not a source) [...] > Here, framerSource->getSPSandPPS() never gets called because at this point > fOurFragmenter is NULL. It looks like you haven't even started playing the stream - i.e., you've never even called "startPlaying()" on your "H264VideoRTPSink" object! Note, however, that if you're using a RTP server, then this should all be happening automatically (once you get the first re quest from a RTSP client). Make sure that you're implementing the virtual functions "createNewStreamSource()" and "createNewRTPSink()" properly. Another thing you can do - because you know the SPS/PPS NAL units in advance - is pass them as parameters to one of the alternative forms of "H264VideoRTPSink::createNew()", which you call from your "createNewRTPSink()" virtual function implementation. (See "liveMedia/include/H264VideoRTPSink.hh") Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Aug 1 11:00:18 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 1 Aug 2013 20:00:18 +0200 Subject: [Live-devel] memory leaks destroying RTSPClient ? Message-ID: <24173_1375380020_51FAA233_24173_4492_1_1BE8971B6CFF3A4F97AF4011882AA255015637F30533@THSONEA01CMS01P.one.grp> Hi Ross, Using your last release 2013.07.31, I faced a memory leak. Debugging show that RTSPClient::~RTSPClient -> RTPInterface::clearServerRequestAlternativeHandler with socketNum = -1 -> RTPInterface::setServerRequestAlternativeHandler -> lookupServerDescriptor -> create env->liveMediaPriv and add -1 in the hashMap Next the call to UsageEnvironment::reclaim doesnot call its private destructor because a socket is still registered. Adding in the RTSPClient destructor if (fInputSocketNum != -1) RTPInterface::clearServerRequestAlternativeHandler(envdir(),fInputSocketNum) make the leaks disappear. I suspect either a problem with the last setServerRequestAlternativeHandler modification or it is now needed to do something before deleting an RTSPClient ? Sorry for the telegraphic mail ! Thanks for your support, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 1 14:31:03 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Aug 2013 23:31:03 +0200 Subject: [Live-devel] memory leaks destroying RTSPClient ? In-Reply-To: <24173_1375380020_51FAA233_24173_4492_1_1BE8971B6CFF3A4F97AF4011882AA255015637F30533@THSONEA01CMS01P.one.grp> References: <24173_1375380020_51FAA233_24173_4492_1_1BE8971B6CFF3A4F97AF4011882AA255015637F30533@THSONEA01CMS01P.one.grp> Message-ID: <926FDFDF-B397-47DA-97C2-69F1A3A7340C@live555.com> Thanks for the report. This (tiny) memory leak can be fixed by changing line 190 of "liveMedia/RTPInterface.cpp" from SocketDescriptor* socketDescriptor = lookupSocketDescriptor(env, socketNum); to SocketDescriptor* socketDescriptor = lookupSocketDescriptor(env, socketNum, False); This will be fixed in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 2 02:24:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Aug 2013 11:24:35 +0200 Subject: [Live-devel] Multicast addresses for MPEG4 and H.264 streams In-Reply-To: <7902889F9975EE44A11D94D3D485EA14BF6AB4@amgsrv01.AMGSYSTEMS.local> References: <7902889F9975EE44A11D94D3D485EA14BF6AB4@amgsrv01.AMGSYSTEMS.local> Message-ID: > The FAQ mentions that the testMPEG4VideoStreamer program incorporates an > RTSP server to provide the SDP description - is this why the RTP > multicast stream is accessed using the RTSP unicast address ? Yes. > VLC instructions (http://www.videolan.org/doc/play-howto/en/ch04.html) > suggest an RTP multicast stream can be received using > rtp://@:1234/, however VLC does not display a video > stream when this address is used - is this because it cannot decode the > stream as it doesn't have the information required ? This is not a VLC mailing list. But the answer is probably Yes. VLC cannot understand the video stream without also knowing the 'configuration' information in the stream. This is included in the SDP description. > Each stream's ServerMediaSession reference count (from > sms->referenceCount(), where sms was created with ServerMediaSession > *sms = ServerMediaSession::createNew(...) ) increments with each new > multicast connection. Is this a count of the number of clients Yes. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 2 06:40:49 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Aug 2013 15:40:49 +0200 Subject: [Live-devel] Multicast addresses for MPEG4 and H.264 streams In-Reply-To: <7902889F9975EE44A11D94D3D485EA14BF6ABA@amgsrv01.AMGSYSTEMS.local> References: <51EEB128.7020508@amgsystems.com> <7902889F9975EE44A11D94D3D485EA14BF6ABA@amgsrv01.AMGSYSTEMS.local> Message-ID: <1B632329-EB3F-4677-B489-013598984C13@live555.com> > Can live555 stream H.264 or MPEG4 video to rtp://:1234 > without using RTSP to set-up the stream (e.g. the client might be on a > different subnet to the live555 server) ? There are (from what I can tell) two different questions here: 1/ Can LIVE555 stream H.264 or MPEG4 video to rtp://:1234 without using RTSP to set-up the stream Yes, (although note that the "rtp://" URL is nonstandard, and is used only by (some) receivers - e.g., VLC - and has nothing to do with our code). Note, though, that H.264 and MPEG-4 video streams contain special configuration parameters that often cause a stream to not be understandable by receivers, unless they get these parameters 'out of band' - e.g., via a SDP description. That's why we recommend that H.264 or MPEG-4 video streams be served via RTSP. 2/ Can multicast streams be received by receivers that are on a different subnet from the sender. This depends entirely on whether your network has set up IP multicast routing between the sender's network and the receiver(s) network(s). It has absolutely nothing to do with application-level code like LIVE555. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at amgsystems.com Fri Aug 2 07:38:54 2013 From: piers.hawksley at amgsystems.com (Piers Hawksley) Date: Fri, 2 Aug 2013 15:38:54 +0100 Subject: [Live-devel] Multicast addresses for MPEG4 and H.264 streams In-Reply-To: References: Message-ID: <7902889F9975EE44A11D94D3D485EA14BF6AC7@amgsrv01.AMGSYSTEMS.local> Thanks Ross, >>1/ Can LIVE555 stream H.264 or MPEG4 video to rtp://:1234 without using RTSP to set-up the stream >Yes, (although note that the "rtp://" URL is nonstandard, and is used only by (some) receivers - e.g., VLC - and has nothing to do with our code). Note, though, that H.264 and MPEG-4 video streams contain special configuration parameters that often cause a stream to not be understandable by receivers, unless they get these parameters 'out of band' - e.g., via a SDP description. That's why we recommend that H.264 or MPEG-4 video streams be served via RTSP. Thanks for clarifying - I have made an sdp file (using the response to the RTSP Describe message and reading RFC 4566) which I can use to provide the stream details to VLC. >>2/ Can multicast streams be received by receivers that are on a different subnet from the sender. >This depends entirely on whether your network has set up IP multicast routing between the sender's network and the receiver(s) network(s). It has absolutely nothing to do with application-level code like LIVE555. I was thinking that RTSP would not work if the live 555 server and the client (viewer) are on different subnets as the client wouldn't be able to reach the server. In this case an sdp file should be suitable - have I understood this correctly ? >>Is the password authentication causing a problem ? Can RTP multicast streams have any authentication ? We use an authentication database with the RTSP server, but the multicast stream (accessed using the info in an sdp file) are freely accessible. Is it up to me to securely distribute the sdp file(s) or is there another way to secure multicast streams ? Many thanks, Piers From finlayson at live555.com Fri Aug 2 12:54:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Aug 2013 14:54:55 -0500 Subject: [Live-devel] bad file descritor In-Reply-To: References: Message-ID: <1A515CF7-60BB-461F-AA2D-BA41488497EA@live555.com> > when clients up to FD_SETSIZE, terminal print error string "BasicTaskScheduler::SingleStep(): select() fails" > and I add debug printf("%s",strerr(errno)); It print "bad file descritor" quickly, and never remove the bad file descritor; I suspect that you are using an out-of-date version of the library, because a bug like this was fixed in a recent release. Please upgrade to the latest version: http://www.live555.com/liveMedia/faq.html#latest-version Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkordani at lsa2.com Fri Aug 2 20:41:22 2013 From: jkordani at lsa2.com (Joshua Kordani) Date: Fri, 02 Aug 2013 23:41:22 -0400 Subject: [Live-devel] testRTSPClient doesn't receive sdp after issuing describe request Message-ID: <51FC7BE2.9030200@lsa2.com> Greetings all I am trying to figure out what I need to do to use liveMedia to source an h264 stream. I am using a BasicTaskScheduler, passed to a BasicUsageEnvironment, passed to an RTSPServer and a ServerMediaSession, in which I add a subsession of type MPEG4VideoFileServerMediaSubsession, which is configured to read data from a pipe. On the data input end, I have nals encoded from x264 that I am simply dumping into this pipe. When I use testRTSPClient on this server, I never get an sdp out of it. output below. ./testRTSPClient rtsp://192.168.4.192:5554/mystream Opening connection to 192.168.4.192, port 5554... ...remote connection opened Sending request: DESCRIBE rtsp://192.168.4.192:5554/mystream RTSP/1.0 CSeq: 2 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2013.06.30) Accept: application/sdp [URL:"rtsp://192.168.4.192:5554/mystream"]: Failed to get a SDP description: liveMedia0 [URL:"rtsp://192.168.4.192:5554/mystream"]: Closing the stream. I am having a heck of a time sussing out how I'm supposed to stand up the various classes and what is expected to be provided by the user (me) and what is automatically generated. I haven't yet figured out where I'm supposed to indicate to liveMedia that I'm passing it H264 data, (so that it may package it properly). Appreciate any pointers! Joshua Kordani -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Aug 3 04:02:52 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 3 Aug 2013 04:02:52 -0700 Subject: [Live-devel] testRTSPClient doesn't receive sdp after issuing describe request In-Reply-To: <51FC7BE2.9030200@lsa2.com> References: <51FC7BE2.9030200@lsa2.com> Message-ID: > I am using a BasicTaskScheduler, passed to a BasicUsageEnvironment, passed to an RTSPServer and a ServerMediaSession, in which I add a subsession of type > MPEG4VideoFileServerMediaSubsession, which is configured to read data from a pipe. I suspect that your problem is that you are blocking while reading from the pipe. Because LIVE555 applications are single-threaded, you can't do that. You need to make sure that reads from the pipe are non-blocking (& asynchronous). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Aug 3 14:40:34 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 3 Aug 2013 14:40:34 -0700 Subject: [Live-devel] Streaming H.264 with MPEG2TS via BasicUDPSink In-Reply-To: <1B8CE959541B0C40BEC5966000F63EC6AD9846C5@MAILBX03.quanta.corp> References: <1B8CE959541B0C40BEC5966000F63EC6AD9846C5@MAILBX03.quanta.corp> Message-ID: > I'm trying to use live555 to stream H.264 video which is encoded by x264 and the video source is webcam. > > I?ve tried > - Write my own FramedSource subclass based on DeviceSource > - Use my own FramedSource, H264VideoStreamFramer and H264VideoRTPSink to stream by RTP. > - Use my own FramedSource, H264VideoStreamFramer, MPEG2TransportStreamFromESSource and BasicUDPSink to MPEG2TS stream by UDP. > In the RTP case, it works fine. You should continue to use H.264/RTP streaming whenever possible. It is more efficient than streaming Transport Stream data (over either RTP or UDP). Also, streaming over raw UDP (i.e., without RTP framing) is discouraged, because - without RTP - you miss out on several benefits, including support for reordering out-of-order packets, and RTCP statistics. Nonetheless... > However, in the UDP case, it got broken image by VLC player often. One thing that I would check is the size of the (Transport Stream) payload that gets delivered to your "BasicUDPSink". When streaming Transport Stream data, this *must* be a multiple of the 188-byte Transport 'packet size'. I suggest setting the (otherwise optional) "maxPayloadSize" parameter to "BasicUDPSInk::createNew()" to 1316 (== 7*188). > Therefore, I changed my video frame source from H264VideoStreamFramer to H264VideoStreamDiscreteFramer Note that if your input device delivers discrete H.264 NAL units - i.e., one at a time, then you *must* use a "H264VideoStreamDiscreteFramer". If your input device delivers a byte stream (containing H.264 NAL units that are separated by 0x00 0x00 0x00 0x01), then you *must* use a "H264VideoStreamFramer" (not a "H264VideoStreamDiscreteFramer"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Mon Aug 5 00:36:37 2013 From: ashvyrkin at gosniias.ru (Andrey Shvyrkin) Date: Mon, 05 Aug 2013 11:36:37 +0400 Subject: [Live-devel] Jerks when playing h264 stream Message-ID: <51FF5605.1000609@gosniias.ru> Hi, Ross. When developing a client application to display the rtsp stream, I ran into a problem when decoding h264 stream. As I am using ffmpeg decoder. I get a SDP description, parses on the SPS and PPS nal units, adding start codes and direct input to the decoder. Each received nal unit I also add a start code. Stream is decoded without any problems, and I get the appropriate shots, but on some h264 streams arise judder. When decoding jpeg and mpeg4 streams such jerks not. First, I have sinned in the decoder, but it turned out that this decoder packages sometimes come with a noticeable delay. The delay occurs when receiving IDR frames (nal unit type 5). Although no presentation time delay. Since SPS and PPS nal units are not useful frames, the difference in time between the IDR frame and the frame normally reaches almost two-fold increase on the match against the usual interval. This presents a judder. It is worth noting that the VLC player plays the stream without jerks. Here is my log output in the first column of the type of unit, the second real time between two packets in milliseconds, in the third - the difference between the presentation times in microseconds: [URL:"rtsp://192.168.33.77/yard(road).264/"]: Got a SDP description: v=0 o=- 1375685540786756 1 IN IP4 192.168.33.77 s=H.264 Video, streamed by the LIVE555 Media Server i=yard(road).264 t=0 0 a=tool:LIVE555 Streaming Media v2013.03.31 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server a=x-qt-text-inf:yard(road).264 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=42C01E;sprop-parameter-sets=Z0LA HqtAWAk2AiAAAAMAIAAABlHixdQ=,aM4yyA== a=control:track1 [URL:"rtsp://192.168.33.77/yard(road).264/"]: Initiated the "video/H264" subsess ion (client ports 52996-52997) [URL:"rtsp://192.168.33.77/yard(road).264/"]: Set up the "video/H264" subsession (client ports 52996-52997) [URL:"rtsp://192.168.33.77/yard(road).264/"]: Created a data sink for the "video /H264" subsession [URL:"rtsp://192.168.33.77/yard(road).264/"]: Started playing session... nal type 6 real time 0 presentation time 0 nal type 7 real time 1 presentation time 0 nal type 8 real time 0 presentation time 0 nal type 5 real time 42 presentation time 0 nal type 1 real time 1 presentation time 40000 nal type 1 real time 37 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 79 presentation time 40000 nal type 1 real time 2 presentation time 40000 nal type 7 real time 38 presentation time 40000 nal type 8 real time 1 presentation time 0 nal type 5 real time 44 presentation time 0 nal type 1 real time 1 presentation time 40000 nal type 1 real time 34 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 80 presentation time 40000 nal type 1 real time 1 presentation time 40000 nal type 7 real time 40 presentation time 40000 nal type 8 real time 1 presentation time 0 nal type 5 real time 45 presentation time 0 nal type 1 real time 1 presentation time 40000 nal type 1 real time 33 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 7 real time 40 presentation time 39988 nal type 8 real time 1 presentation time 0 nal type 5 real time 44 presentation time 0 nal type 1 real time 1 presentation time 40000 nal type 1 real time 33 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 7 real time 40 presentation time 40000 nal type 8 real time 2 presentation time 0 nal type 5 real time 44 presentation time 0 nal type 1 real time 0 presentation time 40000 nal type 1 real time 34 presentation time 40000 nal type 1 real time 41 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 39 presentation time 40000 nal type 7 real time 40 presentation time 40000 nal type 8 real time 2 presentation time 0 nal type 5 real time 41 presentation time 0 nal type 1 real time 0 presentation time 40000 nal type 1 real time 37 presentation time 40000 nal type 1 real time 41 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 37334 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 39 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 7 real time 40 presentation time 40000 nal type 8 real time 1 presentation time 0 nal type 5 real time 45 presentation time 0 nal type 1 real time 0 presentation time 40000 nal type 1 real time 34 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 41 presentation time 40000 nal type 7 real time 40 presentation time 40000 nal type 8 real time 1 presentation time 0 nal type 5 real time 45 presentation time 0 nal type 1 real time 1 presentation time 40000 nal type 1 real time 33 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 7 real time 40 presentation time 40000 nal type 8 real time 1 presentation time 0 nal type 5 real time 43 presentation time 0 nal type 1 real time 1 presentation time 40000 nal type 1 real time 34 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 39988 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 7 real time 40 presentation time 40000 nal type 8 real time 1 presentation time 0 nal type 5 real time 44 presentation time 0 nal type 1 real time 1 presentation time 40000 nal type 1 real time 35 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 nal type 1 real time 40 presentation time 40000 From jkordani at lsa2.com Mon Aug 5 07:57:05 2013 From: jkordani at lsa2.com (Joshua Kordani) Date: Mon, 05 Aug 2013 10:57:05 -0400 Subject: [Live-devel] testRTSPClient doesn't receive sdp after issuing describe request In-Reply-To: References: <51FC7BE2.9030200@lsa2.com> Message-ID: <51FFBD41.2070007@lsa2.com> It can't be because I'm using a MPEG4 video subsession instead of an H264? I made this change and I am further along. My original question still stands though, and that is, where can I go to read up on how to properly stand up this kind of stream? Josh On 8/3/13 7:02 AM, Ross Finlayson wrote: >> I am using a BasicTaskScheduler, passed to a BasicUsageEnvironment, >> passed to an RTSPServer and a ServerMediaSession, in which I add a >> subsession of type >> MPEG4VideoFileServerMediaSubsession, which is configured to read data >> from a pipe. > > I suspect that your problem is that you are blocking while reading > from the pipe. Because LIVE555 applications are single-threaded, you > can't do that. You need to make sure that reads from the pipe are > non-blocking (& asynchronous). > > > 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 ben.willcox at willcoxonline.com Mon Aug 5 14:03:28 2013 From: ben.willcox at willcoxonline.com (Ben Willcox) Date: Mon, 05 Aug 2013 22:03:28 +0100 Subject: [Live-devel] openRTSP teardown problem Message-ID: <52001320.7030107@willcoxonline.com> Hello All, I have a problem with openRTSP capturing a stream from an Axis 210A IP camera as described below: Running Debian Lenny, I run the following command to capture an RTSP stream using TCP from the Axis camera: openRTSP -4 -n -t -Q -b 512000 -u -w 640 -h 480 -f 25 rtsp:///mpeg4/media.amp >output.mp4 I can then stop the stream by issuing 'kill -HUP ' and the video file is created correctly. All is well. However, since upgrading the operating system to Ubuntu 12.04, running the same command and the same HUP signal, the stream does not teardown and openRTSP hangs. Unfortunately this causes a serious problem as I call openRTSP from a Perl application, which then blocks as openRTSP never exits. Sometimes the HUP will complete successfully once, but then capturing a new stream at a later time it will hang. The output after sending the HUP is as follows: ------------------------- inter_packet_gap_ms_min 1.214000 inter_packet_gap_ms_ave 29.394320 inter_packet_gap_ms_max 275.576000 end_QOS_statistics Sending request: TEARDOWN rtsp://:554/mpeg4/media.amp/ RTSP/1.0 CSeq: 7 User-Agent: openRTSP (LIVE555 Streaming Media v2011.12.23) Session: 0929340996 ------------------------- But the session doesn't close. With the Debian Lenny version the openRTSP process exits after the 'end_QOS_statistics' line, consistently. I have discovered that on the 'bad' system if I eliminate the -t switch and therefore stream using UDP, the stream correctly terminates on receiving the HUP. However my application cannot tolerate any frame drop, so this is not a sufficient workaround. I'm afraid I don't know how to obtain version numbers from openRTSP itself, hence I'm referring to the packages included in the Debian Lenny and Ubuntu 12.04 repositories. Any guidance would be appreciated, I'm happy to do any debugging as necessary to help pinpoint this issue. Many thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 5 14:12:26 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Aug 2013 14:12:26 -0700 Subject: [Live-devel] openRTSP teardown problem In-Reply-To: <52001320.7030107@willcoxonline.com> References: <52001320.7030107@willcoxonline.com> Message-ID: > User-Agent: openRTSP (LIVE555 Streaming Media v2011.12.23) You're running a (very!) old version of the "LIVE555 Streaming Media" software. You should upgrade. > I'm afraid I don't know how to obtain version numbers from openRTSP itself, hence I'm referring to the packages included in the Debian Lenny and Ubuntu 12.04 repositories. See http://www.live555.com/liveMedia/faq.html#latest-version In general, people shouldn't use the version of the software that's included in Linux 'distributions', as it's often very out of date (as it was in this case). Instead, download the latest version of the software directly from our web site, as noted above. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.willcox at willcoxonline.com Mon Aug 5 14:42:47 2013 From: ben.willcox at willcoxonline.com (Ben Willcox) Date: Mon, 05 Aug 2013 22:42:47 +0100 Subject: [Live-devel] openRTSP teardown problem In-Reply-To: References: <52001320.7030107@willcoxonline.com> Message-ID: <52001C57.4080804@willcoxonline.com> On 05/08/13 22:12, Ross Finlayson wrote: >> User-Agent: openRTSP (LIVE555 Streaming Media v2011.12.23) > > You're running a (very!) old version of the "LIVE555 Streaming Media" > software. You should upgrade. > Ross, thanks for the very quick response. I've downloaded the latest version and compiled it, and indeed the problem is fixed! This problem has caused me headaches for some time, I should have thought of doing this first. Many thanks for your help, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.willcox at willcoxonline.com Mon Aug 5 14:54:38 2013 From: ben.willcox at willcoxonline.com (Ben Willcox) Date: Mon, 05 Aug 2013 22:54:38 +0100 Subject: [Live-devel] openRTSP teardown problem In-Reply-To: References: <52001320.7030107@willcoxonline.com> Message-ID: <52001F1E.1060401@willcoxonline.com> Ahh, seems I was a bit premature with my last reply, in my excitement I had been running the command without the -t switch which doesn't show the problem. Now if I run the full command again I get the following in the openRTSP output after the -HUP signal: ---------------------- inter_packet_gap_ms_min 0.014000 inter_packet_gap_ms_ave 29.593224 inter_packet_gap_ms_max 350.733000 end_QOS_statistics Sending request: TEARDOWN rtsp://:554/mpeg4/media.amp/ RTSP/1.0 CSeq: 7 User-Agent: /usr/local/bin/openRTSP (LIVE555 Streaming Media v2013.07.31) Session: 0723151412 ---------------------- and the output hangs. If I keep sending HUP signals it says: Got shutdown signal but still doesn't exit. Is there anything else I can try? Thanks, Ben From finlayson at live555.com Mon Aug 5 16:45:13 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Aug 2013 16:45:13 -0700 Subject: [Live-devel] openRTSP teardown problem In-Reply-To: <52001F1E.1060401@willcoxonline.com> References: <52001320.7030107@willcoxonline.com> <52001F1E.1060401@willcoxonline.com> Message-ID: <951C86CE-89C8-44D8-A1B5-9FC2D9BF7984@live555.com> > Sending request: TEARDOWN rtsp://:554/mpeg4/media.amp/ RTSP/1.0 > CSeq: 7 > User-Agent: /usr/local/bin/openRTSP (LIVE555 Streaming Media v2013.07.31) > Session: 0723151412 > ---------------------- > > and the output hangs. OK, the problem here is with the *server* - it should not be hanging when it receives the client's "TEARDOWN" command. Please contact the server's manufacturer, and tell them to fix this problem. However, to allow for this situation occurring (the server hanging on "TEARDOWN"), I have now installed a new version (2013.08.05) of the "LIVE555 Streaming Media" code that updates the "openRTSP" command so that if it is signaled to end (via "kill -HUP"), then it no longer waits for a response to the "TEARDOWN" command. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 5 18:14:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Aug 2013 18:14:36 -0700 Subject: [Live-devel] Multicast addresses for MPEG4 and H.264 streams In-Reply-To: <7902889F9975EE44A11D94D3D485EA14BF6AC7@amgsrv01.AMGSYSTEMS.local> References: <7902889F9975EE44A11D94D3D485EA14BF6AC7@amgsrv01.AMGSYSTEMS.local> Message-ID: > I was thinking that RTSP would not work if the live 555 server and the > client (viewer) are on different subnets as the client wouldn't be able > to reach the server. [...] have > I understood this correctly ? No, you haven't understood this correctly - because RTSP (the control protocol) runs over TCP, and so will work over any number of 'subnets'. However, if the RTSP session is describing a multicast stream, then this stream may or may not be able to be received on a different 'subnet', depending on whether or not your network implements IP multicast routing. (As I noted in my last message, that has absolutely nothing to do with our software.) > Can RTP multicast streams have any authentication ? RTSP servers (including ours) support authentication. However, if the RTSP server is serving a multicast stream, then there is nothing to stop someone else (again, on whatever networks are reached by IP multicast routing from the sender) from receiving the multicast stream, simply by listening to the same IP multicast address and port. (In other words, if a RTSP server describes a multicast stream, then that same stream may also be received by other receivers that don't use RTSP. That's not true for unicast streams.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 6 01:17:32 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 6 Aug 2013 01:17:32 -0700 Subject: [Live-devel] Jerks when playing h264 stream In-Reply-To: <51FF5605.1000609@gosniias.ru> References: <51FF5605.1000609@gosniias.ru> Message-ID: > It is worth noting that the VLC player plays the stream without jerks. That's good news, because VLC - like your application - also uses the "LIVE555 Streaming Media" code, and FFMPEG. That gives you working code that may help you solve your problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Tue Aug 6 01:51:03 2013 From: ashvyrkin at gosniias.ru (Andrey Shvyrkin) Date: Tue, 06 Aug 2013 12:51:03 +0400 Subject: [Live-devel] Jerks when playing h264 stream In-Reply-To: References: <51FF5605.1000609@gosniias.ru> Message-ID: <5200B8F7.8080902@gosniias.ru> 06.08.2013 12:17, Ross Finlayson ?????: >> It is worth noting that the VLC player plays the stream without jerks. > > That's good news, because VLC - like your application - also uses the > "LIVE555 Streaming Media" code, and FFMPEG. That gives you working > code that may help you solve your problem. > > > 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 I guess in VLC jerks eliminated thanks to the buffer. I just wanted to understand why the presentation of the group of units (SPS, PPS and IDR) is the same, but really the SPS and PPS come without delay, and IDR frame with a delay of 40 milliseconds in accordance with the FPS? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.willcox at willcoxonline.com Tue Aug 6 23:26:20 2013 From: ben.willcox at willcoxonline.com (Ben Willcox) Date: Wed, 07 Aug 2013 07:26:20 +0100 Subject: [Live-devel] openRTSP teardown problem In-Reply-To: <951C86CE-89C8-44D8-A1B5-9FC2D9BF7984@live555.com> References: <52001320.7030107@willcoxonline.com> <52001F1E.1060401@willcoxonline.com> <951C86CE-89C8-44D8-A1B5-9FC2D9BF7984@live555.com> Message-ID: <5201E88C.2000100@willcoxonline.com> On 06/08/13 00:45, Ross Finlayson wrote: > OK, the problem here is with the *server* - it should not be hanging > when it receives the client's "TEARDOWN" command. Please contact the > server's manufacturer, and tell them to fix this problem. > > However, to allow for this situation occurring (the server hanging on > "TEARDOWN"), I have now installed a new version (2013.08.05) of the > "LIVE555 Streaming Media" code that updates the "openRTSP" command so > that if it is signaled to end (via "kill -HUP"), then it no longer > waits for a response to the "TEARDOWN" command. Thanks Ross the new version solves my problem, many thanks for your assistance with this. This particular model of IP camera is fairly old now and the manufacturer no longer offer support on it, so I imagine they will not be interested in applying a fix - hopefully their newer products no longer have this defect . Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghav at fossilshale.com Wed Aug 7 05:09:02 2013 From: raghav at fossilshale.com (raghav at fossilshale.com) Date: Wed, 07 Aug 2013 17:39:02 +0530 Subject: [Live-devel] Problem with G726-16 Audio Streaming Message-ID: <20130807173902.17326pnpi008qs4e@mail.fossilshale.com> Hi Ross, Can live555 Server supports G726-16 audio format?.When i tried to play this format using vlc as client its playing too fast(with 64kbps).Do i need to do any modifications in the code so that it can stream normal bitrate.? Thanks in Advance. Regards, Raghav From finlayson at live555.com Wed Aug 7 06:40:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 7 Aug 2013 06:40:07 -0700 Subject: [Live-devel] Problem with G726-16 Audio Streaming In-Reply-To: <20130807173902.17326pnpi008qs4e@mail.fossilshale.com> References: <20130807173902.17326pnpi008qs4e@mail.fossilshale.com> Message-ID: <78659534-1676-4144-8DE5-DC03F59D0859@live555.com> > Can live555 Server supports G726-16 audio format?. Yes. > When i tried to play this format using vlc as client its playing too fast(with 64kbps). OK, this is a problem with VLC - not our software. You will need to contact a VLC mailing list, telling them about the problem, and giving them a "rtsp://" URL of a (publically-accessible) stream that illustrates the problem. > Do i need to do any modifications in the code so that it can stream normal bitrate.? Yes, but the 'code' that you would need to modify is VLC code, not ours. (Or you can ask the VLC people to fix the problem themselves.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.reinhold at rccny.com Sat Aug 10 13:06:05 2013 From: joseph.reinhold at rccny.com (Joseph Reinhold) Date: Sat, 10 Aug 2013 20:06:05 +0000 Subject: [Live-devel] extending Message-ID: I having great deal of problems extending the handleCmd_GET_PARAMETER method Please help -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Aug 10 13:46:19 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 10 Aug 2013 13:46:19 -0700 Subject: [Live-devel] extending In-Reply-To: References: Message-ID: > I having great deal of problems extending the handleCmd_GET_PARAMETER method That's rather vague (to put it mildly :-) Can you explain specifically what trouble you're having? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Sun Aug 11 22:36:58 2013 From: kingaceck at 163.com (kingaceck) Date: Mon, 12 Aug 2013 13:36:58 +0800 Subject: [Live-devel] streaming aac file Message-ID: <201308121336576963731@163.com> Live555 can streaming aac file(test.aac). But when playing ,the vlc has no process bar and the total time's indicator(it's 00:00 at the lower right corner of vlc). I can't jump to another point to play in the vlc process bar area. what's the reason of this? (I play the aac file using vlc directly and all is right.) 2013-08-12 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Aug 11 22:45:09 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 11 Aug 2013 22:45:09 -0700 Subject: [Live-devel] streaming aac file In-Reply-To: <201308121336576963731@163.com> References: <201308121336576963731@163.com> Message-ID: <7BF61EB1-E190-4D79-923E-0FA7BB412DD9@live555.com> > Live555 can streaming aac file(test.aac). But when playing ,the vlc has no process bar and the total time's indicator(it's 00:00 at the lower right corner of vlc). I can't jump to another point to play in the vlc process bar area. > what's the reason of this? Because our RTSP server implementation currently does not support seeking when streaming a ".aac" file. http://www.live555.com/liveMedia/faq.html#trick-mode Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.reinhold at rccny.com Mon Aug 12 09:56:11 2013 From: joseph.reinhold at rccny.com (Joseph Reinhold) Date: Mon, 12 Aug 2013 16:56:11 +0000 Subject: [Live-devel] extend cont. Message-ID: Reference ---- ------------------------------ Message: 4 Date: Sat, 10 Aug 2013 20:06:05 +0000 From: Joseph Reinhold > To: "live-devel at lists.live555.com" > Subject: [Live-devel] extending Message-ID: > Content-Type: text/plain; charset="us-ascii" I having great deal of problems extending the handleCmd_GET_PARAMETER method Please help -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Sat, 10 Aug 2013 13:46:19 -0700 From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] extending Message-ID: > Content-Type: text/plain; charset="us-ascii" > I having great deal of problems extending the handleCmd_GET_PARAMETER > method That's rather vague (to put it mildly :-) Can you explain specifically what trouble you're having? Occurring to 555 notes void RTSPServer::RTSPClientSession ::handleCmd_GET_PARAMETER(RTSPServer::RTSPClientConnection* ourClientConnection, ServerMediaSubsession* /*subsession*/, char const* /*fullRequestStr*/) { // By default, we implement "GET_PARAMETER" just as a 'keep alive', and send back a dummy response. // (If you want to handle "GET_PARAMETER" properly, you can do so by defining a subclass of "RTSPServer" // and "RTSPServer::RTSPClientSession", and then reimplement this virtual function in your subclass.) ourClientConnection->setRTSPResponse("200 OK", fOurSessionId, LIVEMEDIA_LIBRARY_VERSION_STRING); } I should be able to extend handleCmd_GET_PARAMETER I getting all sort of issues I can not expand These a copies of the files that I am using in an attempt to extend this method /***************** *************************** ** RADIANT extension for RTSPServer *********************************************/ #ifndef _RTSP_SERVEREXTENSIONS_HH #define _RTSP_SERVEREXTENSIONS_HH class RTSPServerExtensions :protected RTSPServer { public: RTSPServerExtensions(UsageEnvironment& env, int ourSocket, Port ourPort, UserAuthenticationDatabase* authDatabase, unsigned int y) {} ~RTSPServerExtensions(){} public: class RTSPClientConnectionExtension: protected RTSPServer:: RTSPClientConnection { public: ~RTSPClientConnectionExtension(){} RTSPClientConnectionExtension(RTSPServer& ourServer, int clientSocket, struct sockaddr_in clientAddr){} public: void handleCmd_GET_PARAMETER(RTSPClientConnection* ourClientConnection, ServerMediaSubsession* subsession, char const* fullRequestStr); void handleCmd_SET_PARAMETER(RTSPClientConnection* ourClientConnection, ServerMediaSubsession* subsession, char const* fullRequestStr); void handleCmd_GET_PARAMETER(char const* fullRequestStr); // when operating on the entire server void handleCmd_SET_PARAMETER(char const* fullRequestStr); // when operating on the entire server private: }; }; #endif #include "RTSPServer.hh" #include "RTSPCommon.hh" #include "RTSPServerExtensions.hh" #include "ProxyServerMediaSession.hh" #include "Base64.hh" #include #include "RTSPServerExtensions.hh" void RTSPServerExtensions::RTSPClientConnectionExtension::handleCmd_GET_PARAMETER(RTSPServer::RTSPClientConnection* ourClientConnection, ServerMediaSubsession* /*subsession*/, char const* fullRequestStr) { if(0 == fOurServer.fClientSessions->Lookup(fOurServer.sessionIdStr)) { } else { // ptr->setRTSPResponse("200 OK",fOurSessionId, LIVEMEDIA_LIBRARY_VERSION_STRING); ourClientConnection->setRTSPResponse ("200 OK",fOurSessionId, LIVEMEDIA_LIBRARY_VERSION_STRING); } // By default, we implement "GET_PARAMETER" just as a 'keep alive', and send back a dummy response. // (If you want to handle "GET_PARAMETER" properly, you can do so by defining a subclass of "RTSPServer" // and "RTSPServer::RTSPClientSession", and then reimplement this virtual function in your subclass.) // ourClientConnection->setRTSPResponse("200 OK", RTSPClientSession::fOurSessionId, LIVEMEDIA_LIBRARY_VERSION_STRING); } void RTSPServerExtensions::RTSPClientConnectionExtension ::handleCmd_SET_PARAMETER(RTSPServer::RTSPClientConnection* ourClientConnection, ServerMediaSubsession* /*subsession*/, char const* /*fullRequestStr*/) { // By default, we implement "SET_PARAMETER" just as a 'keep alive', and send back an empty response. // (If you want to handle "SET_PARAMETER" properly, you can do so by defining a subclass of "RTSPServer" // and "RTSPServer::RTSPClientSession", and then reimplement this virtual function in your subclass.) // ourClientConnection->setRTSPResponse("200 OK", fOurSessionId); } void RTSPServerExtensions::RTSPClientConnectionExtension ::handleCmd_GET_PARAMETER(char const* /*fullRequestStr*/) { // By default, we implement "GET_PARAMETER" (on the entire server) just as a 'no op', and send back a dummy response. // (If you want to handle this type of "GET_PARAMETER" differently, you can do so by defining a subclass of "RTSPServer" // and "RTSPServer::RTSPClientConnection", and then reimplement this virtual function in your subclass.) // setRTSPResponse("200 OK", LIVEMEDIA_LIBRARY_VERSION_STRING); } void RTSPServerExtensions:: RTSPClientConnectionExtension ::handleCmd_SET_PARAMETER(char const* /*fullRequestStr*/) { // By default, we implement "SET_PARAMETER" (on the entire server) just as a 'no op', and send back an empty response. // (If you want to handle this type of "SET_PARAMETER" differently, you can do so by defining a subclass of "RTSPServer" // and "RTSPServer::RTSPClientConnection", and then reimplement this virtual function in your subclass.) // setRTSPResponse("200 OK"); } /* RTSPServerExtensions::RTSPServerExtensions(UsageEnvironment& env, int ourSocket, Port ourPort, UserAuthenticationDatabase* authDatabase, unsigned int y) {} */ // these are the errors I am getting make all cd liveMedia; make make[1]: Entering directory `/home/radiant/workspace/RccMediaServer/liveMedia' arm-none-linux-gnueabi-g++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. -g -O0 -DSOCKLEN_T=socklen_t -DNO_SSTREAM=1 -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -Wall -DBSD=1 RTSPServerExtensions.cpp In file included from RTSPServerExtensions.cpp:5: include/RTSPServerExtensions.hh: In constructor 'RTSPServerExtensions::RTSPServerExtensions(UsageEnvironment&, int, Port, UserAuthenticationDatabase*, unsigned int)': make[1]: Leaving directory `/home/radiant/workspace/RccMediaServer/liveMedia' include/RTSPServerExtensions.hh:16: error: no matching function for call to 'RTSPServer::RTSPServer()' include/RTSPServer.hh:146: note: candidates are: RTSPServer::RTSPServer(UsageEnvironment&, int, Port, UserAuthenticationDatabase*, unsigned int) include/RTSPServer.hh:64: note: RTSPServer::RTSPServer(const RTSPServer&) include/RTSPServerExtensions.hh: In constructor 'RTSPServerExtensions::RTSPClientConnectionExtension::RTSPClientConnectionExtension(RTSPServer&, int, sockaddr_in)': include/RTSPServerExtensions.hh:28: error: no matching function for call to 'RTSPServer::RTSPClientConnection::RTSPClientConnection()' include/RTSPServer.hh:175: note: candidates are: RTSPServer::RTSPClientConnection::RTSPClientConnection(RTSPServer&, int, sockaddr_in) include/RTSPServer.hh:173: note: RTSPServer::RTSPClientConnection::RTSPClientConnection(const RTSPServer::RTSPClientConnection&) include/RTSPServer.hh: In member function 'void RTSPServerExtensions::RTSPClientConnectionExtension::handleCmd_GET_PARAMETER(RTSPServer::RTSPClientConnection*, ServerMediaSubsession*, const char*)': include/RTSPServer.hh:141: error: 'char* RTSPServer::sessionIdStr' is protected RTSPServerExtensions.cpp:17: error: within this context RTSPServerExtensions.cpp:25: error: 'fOurSessionId' was not declared in this scope make[1]: *** [RTSPServerExtensions.o] Error 1 make: *** [liveMedia/libliveMedia.a] Error 2 For starters my extension of the 'RTSPServer::RTSPServer is not compling due to the fact that the signature of my constructor does not match 'RTSPServer::RTSPServer 'RTSPServerExtensions::RTSPServerExtensions(UsageEnvironment&, int, Port, UserAuthenticationDatabase*, unsigned int)': RTSPServer::RTSPServer(UsageEnvironment&, int, Port, UserAuthenticationDatabase*, unsigned int) But yet appears to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 12 12:22:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Aug 2013 12:22:36 -0700 Subject: [Live-devel] extend cont. In-Reply-To: References: Message-ID: > class RTSPServerExtensions :protected RTSPServer That's your first problem. When subclassing LIVE555 classes, you should always use public inheritance (because you want a 'is a' relationship), not protected or private inheritance. (Personally, I don't think that protected or private inheritance is a good idea for *any* C++ code.) Second, note that there are two "handleCmd_GET_PARAMETER()" virtual functions (and ditto for "handleCmd_SET_PARAMETER()"). The first one (used to implement commands that operate on the entire server - i.e., "GET_PARAMETER *") is a member function of "RTSPServer::RTSPClientConnection". The second one (used to implement commands that operate within a RTSP session - i.e., for one particular stream, specified by "rtsp://" URL) is a member function of "RTSPServer::RTSPClientSession". Therefore, depending on which virtual function(s) you wish to reimplement, you will need to subclass not just "RTSPServer", but also "RTSPServer::RTSPClientConnection", "RTSPServer::RTSPClientSession", or both. Finally, if you subclass "RTSPServer::RTSPClientConnection", you must also reimplement the virtual function "createNewClientConnection()" in your "RTSPServer" subclass. Similarly, if you subclass "RTSPServer::RTSPClientSession", you must also reimplement the virtual function "createNewClientSession()" in your "RTSPServer" subclass. So, your first step is decide which RTSP operation(s) you *really* want to reimplement. Do you want to reimplement "GET_PARAMETER" (or "SET_PARAMETER") that applies to the whole server, or "GET_PARAMETER" (or "SET_PARAMETER") that applies to one particular stream (specified by "rtsp://" URL)? To illustrate, I assume that you want to reimplement "GET_PARAMETER" when applied to one particular stream. In this case, you'd subclass both "RTSPServer" and "RTSPServer::RTSPClientSession" - like this: class RTSPServerExtension: public RTSPServer { public: static RTSPServerExtension* createNew(UsageEnvironment& env, Port rtspPort = 554, UserAuthenticationDatabase* authDatabase = NULL, unsigned reclamationTestSeconds = 65); protected: RTSPServerExtension(UsageEnvironment& env, int ourSocket, Port ourPort, UserAuthenticationDatabase* authDatabase, unsigned reclamationTestSeconds); // called only by createNew(); virtual ~RTSPServerExtension(); protected: // redefined virtual functions virtual RTSPClientSession* createNewClientSession(u_int32_t sessionId); public: // should be protected, but some old compilers complain otherwise class RTSPClientSessionExtension: public RTSPServer::RTSPClientSession { public: RTSPClientSessionExtension(RTSPServer& ourServer, u_int32_t sessionId); virtual ~RTSPClientSessionExtension(); protected: // redefined virtual functions virtual void handleCmd_GET_PARAMETER(RTSPClientConnection* ourClientConnection, ServerMediaSubsession* subsession, char const* fullRequestStr); }; }; And your implementation would look something like this: RTSPServerExtension* RTSPServerExtension ::createNew(UsageEnvironment& env, Port rtspPort, UserAuthenticationDatabase* authDatabase, unsigned reclamationTestSeconds) { int ourSocket = setUpOurSocket(env, rtspPort); if (ourSocket == -1) return NULL; return new RTSPServerExtension(env, ourSocket, rtspPort, authDatabase, reclamationTestSeconds); } RTSPServerExtension::RTSPServerExtension(UsageEnvironment& env, int ourSocket, Port rtspPort, UserAuthenticationDatabase* authDatabase, unsigned reclamationTestSeconds) : RTSPServer(env, ourSocket, rtspPort, authDatabase, reclamationTestSeconds) { } RTSPServerExtension::~RTSPServerExtension() { } RTSPServer::RTSPClientSession* RTSPServerExtension::createNewClientSession(u_int32_t sessionId) { return new RTSPServerExtension::RTSPClientSessionExtension(*this, sessionId); } RTSPServerExtension::RTSPClientSessionExtension ::RTSPClientSessionExtension(RTSPServer& ourServer, u_int32_t sessionId) : RTSPClientSession(ourServer, sessionId) { } RTSPServerExtension::RTSPClientSessionExtension ::~RTSPClientSessionExtension() { } void RTSPServerExtension::RTSPClientSessionExtension ::handleCmd_GET_PARAMETER(RTSPClientConnection* ourClientConnection, ServerMediaSubsession* subsession, char const* fullRequestStr) { setRTSPResponse(ourClientConnection, "200 OK", fOurSessionId, "my_special_parameter_value"); } Then, in your application code, you'd create a new "RTSPServerExtension" by calling RTSPServerExtension* myRTSPServer = RTSPServerExtension::createNew( etc. ); Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From WILLIAM.C.BOYKIN at saic.com Tue Aug 13 12:37:19 2013 From: WILLIAM.C.BOYKIN at saic.com (Boykin, William C.) Date: Tue, 13 Aug 2013 12:37:19 -0700 Subject: [Live-devel] testH264VideoToTransportStream Frame Rates Message-ID: <1F03D0DC29EC2F4198A8B37F37628CE208A00898@0461-its-exmb05.us.saic.com> Hi, I'd like to know if there is a way to change the frame rate in testprogs : testH264VideoToTransportStream.exe code from 25.0 to 10.0 and get the same reliable video result I see with 25.0 FYI: I tried changing H264VideoStreamFramer.cpp fFrameRate = 25.0; to fFrameRate = 10.0; but the video seems to have breaks or blurs. Bill "Woody" Boykin | SAIC Software Engineer IV | Software Solution Team 6725 Odyssey Drive Huntsville, AL 35806 Room : 370 Phone : 256-971-6738 email : william.c.boykin at saic.com "Knowledge speaks, wisdom listens." ~ Jimi Hendrix -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 13 14:25:53 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Aug 2013 14:25:53 -0700 Subject: [Live-devel] testH264VideoToTransportStream Frame Rates In-Reply-To: <1F03D0DC29EC2F4198A8B37F37628CE208A00898@0461-its-exmb05.us.saic.com> References: <1F03D0DC29EC2F4198A8B37F37628CE208A00898@0461-its-exmb05.us.saic.com> Message-ID: I think you may be confused about the purpose of the initial setting of "fFrameRate" in "H264VideoStreamFramer.cpp". This setting is just a 'guess' - a default setting, to be used if - for some reason - the stream's frame rate cannot be inferred from reading SPS ("Sequence Parameter Set") NAL units. But if really shouldn't be used. Ideally, SPS NAL units will tell you what the stream's frame rate is. But if this can't be done - e.g., because your stream doesn't have any SPS NAL units - then we have to guess the frame rate. In the code, we 'guess' 25 fps, but that may, or may not be correct. The best solution is to have SPS NAL units in your stream that tell you what the frame rate really is. But in your email, you said that the guess of 25 fps gave you 'reliable video', but when you changed the guess to 10 fps, you got bad video. This suggests to me that you were trying to 'change' the video's frame rate - which is not the purpose of this code. If you really want to change a video stream from 25 fps to 10 fps, then you should be dropping frames from the input; not just trying to change the timing information. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhlal83 at gmail.com Tue Aug 13 22:15:26 2013 From: saurabhlal83 at gmail.com (Saurabh Lal) Date: Wed, 14 Aug 2013 10:45:26 +0530 Subject: [Live-devel] Streaming CAS encrypted stream Message-ID: Hi, I am trying to use live 555 to stream an CAS encrypted stream and use trick play on VOD client. Encrypted stream has ECM,EMM and CA packets as compared to original streams. Also PCR is modified as per new packets inserted. I am thinking of changing the index file created from clear stream. Change will be for PCR values and transport packet numbers. Will this change suffice for the trick play support on VOD client or any other change also needs to be done ? Please guide. Thanks & Regards, Saurabh -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Wed Aug 14 09:37:38 2013 From: warren at etr-usa.com (Warren Young) Date: Wed, 14 Aug 2013 10:37:38 -0600 Subject: [Live-devel] testH264VideoToTransportStream Frame Rates In-Reply-To: References: <1F03D0DC29EC2F4198A8B37F37628CE208A00898@0461-its-exmb05.us.saic.com> Message-ID: <520BB252.1010206@etr-usa.com> On 8/13/2013 15:25, Ross Finlayson wrote: > If you really want to > change a video stream from 25 fps to 10 fps, then you should be dropping > frames from the input; That would give very stuttery video -- 10 doesn't divide evenly into 25 -- and isn't practical for an inter-frame codec like H.264 anyway. You can't drop a P frame that has B frames referring to it. What's wrong with just rewriting the timing information in the stream. I don't know H.264 internals, but in MPEG-2 terms, wouldn't scaling all the PTS and DTS values by 2.5x give the desired result? From finlayson at live555.com Wed Aug 14 10:58:53 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Aug 2013 10:58:53 -0700 Subject: [Live-devel] testH264VideoToTransportStream Frame Rates In-Reply-To: <520BB252.1010206@etr-usa.com> References: <1F03D0DC29EC2F4198A8B37F37628CE208A00898@0461-its-exmb05.us.saic.com> <520BB252.1010206@etr-usa.com> Message-ID: > What's wrong with just rewriting the timing information in the stream. I don't know H.264 internals, but in MPEG-2 terms, wouldn't scaling all the PTS and DTS values by 2.5x give the desired result? Perhaps, but I'm not really sure what he 'desires'. Scaling the timing values without dropping any frames would produce a video that plays 'slowly' - i.e., a video that used to last 10 seconds would now last 25 seconds. But if he wants the video to to have a lower frame rate, without looking 'slow', then he'd need to decode/reencode the video. In any case, this is all off-topic for this mailing list. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From WILLIAM.C.BOYKIN at saic.com Wed Aug 14 11:28:44 2013 From: WILLIAM.C.BOYKIN at saic.com (Boykin, William C.) Date: Wed, 14 Aug 2013 11:28:44 -0700 Subject: [Live-devel] testH264VideoToTransportStream Frame Rates References: <1F03D0DC29EC2F4198A8B37F37628CE208A00898@0461-its-exmb05.us.saic.com> <520BB252.1010206@etr-usa.com> Message-ID: <1F03D0DC29EC2F4198A8B37F37628CE208A008A0@0461-its-exmb05.us.saic.com> My email was a bit sketchy but your response makes sense. My AXIS cameras are set to 10 FPS and are save as *.264 video files which I then run thru the testH264VideoToTransportStream.exe to produce the *.ts videos that I then perform KLV encoding. It may be that I'm not receiving or reading the NAL units or that the saved *.264 videos are recorded with out this info.... Thank you both for your input. Bill "Woody" Boykin | SAIC Software Engineer IV | Software Solution Team 6725 Odyssey Drive Huntsville, AL 35806 Room : 370 Phone : 256-971-6738 email : william.c.boykin at saic.com "Knowledge speaks, wisdom listens." ~ Jimi Hendrix ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Wed 8/14/2013 12:58 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testH264VideoToTransportStream Frame Rates What's wrong with just rewriting the timing information in the stream. I don't know H.264 internals, but in MPEG-2 terms, wouldn't scaling all the PTS and DTS values by 2.5x give the desired result? Perhaps, but I'm not really sure what he 'desires'. Scaling the timing values without dropping any frames would produce a video that plays 'slowly' - i.e., a video that used to last 10 seconds would now last 25 seconds. But if he wants the video to to have a lower frame rate, without looking 'slow', then he'd need to decode/reencode the video. In any case, this is all off-topic for this mailing list. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 6560 bytes Desc: not available URL: From chris at gotowti.com Wed Aug 14 11:29:47 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Wed, 14 Aug 2013 11:29:47 -0700 Subject: [Live-devel] base64Decode Drop Trailing Zeros Message-ID: <002101ce991c$42595d90$c70c18b0$@com> Hi Ross, I am using the LIVE555 function base64Decode to decode some base64 data. Usually I want to drop the trailing zeros so I don't end up with extra zeros from the padding data, but if the source data itself contains trailing zeros I would like to keep them. Is there a simple change you would accept to base64Decode, to handle this? I would be happy to send a patch. Thanks, Chris Richardson WTI -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 14 11:55:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Aug 2013 11:55:15 -0700 Subject: [Live-devel] base64Decode Drop Trailing Zeros In-Reply-To: <002101ce991c$42595d90$c70c18b0$@com> References: <002101ce991c$42595d90$c70c18b0$@com> Message-ID: <88344BA8-328F-440B-8944-27A6AC305AF5@live555.com> > I am using the LIVE555 function base64Decode to decode some base64 data. Usually I want to drop the trailing zeros so I don?t end up with extra zeros from the padding data, but if the source data itself contains trailing zeros I would like to keep them. > > Is there a simple change you would accept to base64Decode, to handle this? Mumble... Let's take a look at your suggested patch. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Wed Aug 14 12:30:41 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Wed, 14 Aug 2013 12:30:41 -0700 Subject: [Live-devel] base64Decode Drop Trailing Zeros In-Reply-To: <88344BA8-328F-440B-8944-27A6AC305AF5@live555.com> References: <002101ce991c$42595d90$c70c18b0$@com> <88344BA8-328F-440B-8944-27A6AC305AF5@live555.com> Message-ID: <003801ce9924$c4548970$4cfd9c50$@com> Hi Ross, Thanks for taking a look. Attached you will find the patch. What I am attempting to do is drop only zeros that were generated via padding characters. I'm not sure it is correct for all cases, but I ran a bunch of tests here and it seems to work OK. Thanks, Chris Richardson WTI From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, August 14, 2013 11:55 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] base64Decode Drop Trailing Zeros I am using the LIVE555 function base64Decode to decode some base64 data. Usually I want to drop the trailing zeros so I don't end up with extra zeros from the padding data, but if the source data itself contains trailing zeros I would like to keep them. Is there a simple change you would accept to base64Decode, to handle this? Mumble... Let's take a look at your suggested patch. 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: Base64.cpp.patch Type: application/octet-stream Size: 964 bytes Desc: not available URL: From arash.cordi at gmail.com Wed Aug 14 04:01:03 2013 From: arash.cordi at gmail.com (Arash Cordi) Date: Wed, 14 Aug 2013 15:31:03 +0430 Subject: [Live-devel] authorizing users Message-ID: is it possible to change UserAuthenticationDatabase class so that it can be used to limit user access to specific streams? how else can it be done in live555? -- ArasH -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 14 21:48:48 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Aug 2013 21:48:48 -0700 Subject: [Live-devel] base64Decode Drop Trailing Zeros In-Reply-To: <003801ce9924$c4548970$4cfd9c50$@com> References: <002101ce991c$42595d90$c70c18b0$@com> <88344BA8-328F-440B-8944-27A6AC305AF5@live555.com> <003801ce9924$c4548970$4cfd9c50$@com> Message-ID: <4CE0D53E-4794-47A4-AB60-F4EBBE203395@live555.com> Thanks. This is actually the way that the "trimTrailingZeros" option was supposed to work. I've now installed a new version of the code that includes your fix. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 15 00:44:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Aug 2013 00:44:06 -0700 Subject: [Live-devel] authorizing users In-Reply-To: References: Message-ID: <6179FC13-4CEA-41E0-81E5-9FA86501F4C8@live555.com> > is it possible to change UserAuthenticationDatabase class so that it can be used to limit user access to specific streams? Yes, you can do this; however, you don't need to make any changes to the "UserAuthenticationDatabase" code. Instead, the way you would do this would be to subclass "RTSPServer", and reimplement the virtual function virtual Boolean specialClientUserAccessCheck(int clientSocket, struct sockaddr_in& clientAddr, char const* urlSuffix, char const *username); (see "liveMedia/include/RTSPServer.hh") You would use a (regular, unmodified) "UserAuthenticationDatabase" to first reject users who don't have *any* access to the server. Then, your reimplemented "specialClientUserAccessCheck()" function would reject users who aren't allowed to access the specific stream (named by "urlSuffix") that's being named. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Thu Aug 15 08:53:51 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Thu, 15 Aug 2013 08:53:51 -0700 Subject: [Live-devel] base64Decode Drop Trailing Zeros In-Reply-To: <4CE0D53E-4794-47A4-AB60-F4EBBE203395@live555.com> References: <002101ce991c$42595d90$c70c18b0$@com> <88344BA8-328F-440B-8944-27A6AC305AF5@live555.com> <003801ce9924$c4548970$4cfd9c50$@com> <4CE0D53E-4794-47A4-AB60-F4EBBE203395@live555.com> Message-ID: <006201ce99cf$a44e54c0$eceafe40$@com> Hi Ross, >>Thanks. This is actually the way that the "trimTrailingZeros" option was supposed to work. I've now installed a new version of the code that includes your fix. Thanks for incorporating this change. Chris Richardson WTI -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 16 13:46:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 16 Aug 2013 13:46:46 -0700 Subject: [Live-devel] New LIVE555 version, fixes a bug in Matroska/WebM file parsing Message-ID: <87253E5A-776F-4961-9279-88715332680D@live555.com> If you have a RTSP server that's streaming from Matroska or WebM files (or are parsing these files for some other purpose), then you should upgrade to the latest version (2013.08.16) of the "LIVE555 Streaming Media" code; it fixes a bug in the parsing of 8-byte float values within these files. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Subhankar_Saha at mindtree.com Sat Aug 17 08:37:09 2013 From: Subhankar_Saha at mindtree.com (Subhankar Saha) Date: Sat, 17 Aug 2013 15:37:09 +0000 Subject: [Live-devel] authorizing users In-Reply-To: <6179FC13-4CEA-41E0-81E5-9FA86501F4C8@live555.com> References: <6179FC13-4CEA-41E0-81E5-9FA86501F4C8@live555.com> Message-ID: Hi Ross, We happen to have the same requirement. And I tried your recommendation of subclassing "RTSPServer". In our case, each stream will have different set of username-passwd combination. In other words, username/passwd combination of "Stream-1" should not be allowed to access "Stream-2", and so on. In our case, username could be same across streams, as they are derived from the cameras whose streams are being proxy-ed. But it appears we must create an "authDB", and add all username-passwd combinations of all streams first, while creating the RTSPServer. Only then, it seems to invoke the re-implemented virtual function 'specialClientUserAccessCheck'. Since we do not get the 'passwd' component of the 'username' in 'specialClientUserAccessCheck', how do we restrict an user of "Stream-1" from incorrectly accessing "Stream-2", when the username being same for both streams? Will it be possible to include password as well for 'specialClientUserAccessCheck'? Regards, Subhankar. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, August 15, 2013 1:14 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] authorizing users is it possible to change UserAuthenticationDatabase class so that it can be used to limit user access to specific streams? Yes, you can do this; however, you don't need to make any changes to the "UserAuthenticationDatabase" code. Instead, the way you would do this would be to subclass "RTSPServer", and reimplement the virtual function virtual Boolean specialClientUserAccessCheck(int clientSocket, struct sockaddr_in& clientAddr, char const* urlSuffix, char const *username); (see "liveMedia/include/RTSPServer.hh") You would use a (regular, unmodified) "UserAuthenticationDatabase" to first reject users who don't have *any* access to the server. Then, your reimplemented "specialClientUserAccessCheck()" function would reject users who aren't allowed to access the specific stream (named by "urlSuffix") that's being named. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Philipp.Schrader at nuvation.com Sat Aug 17 20:04:05 2013 From: Philipp.Schrader at nuvation.com (Philipp Schrader) Date: Sat, 17 Aug 2013 20:04:05 -0700 Subject: [Live-devel] emulation bytes in a slice NALU Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE10713B9DF@mailguy3.skynet.nuvation.com> Hi all, I am curious if someone could shed some light on the following assumption in the live555 code: liveMedia/H264VideoStreamFramer.cpp:524: // Note: We assume that there aren't any 'emulation prevention' bytes here to worry about... In our application we're noticing that our frame slices' NALU headers are decoded incorrectly because padding bytes are not stripped. This in turn causes the application to treat the slices as belonging to different frames and seems to slow down the stream. To clarify, this is the NALU byte stream that is causing the issue: 25 00 1F E2 22 00 00 03 02 00 00 80 AB FF When removing the emulation bytes, it turns into 25 00 1F E2 22 00 00 02 00 00 80 AB FF (notice the missing 03) Since this is not happening, however, live555 interprets the idr_pic_id as 769 when it should be 511. At least I think that this kind of thing is what's referred to by the "emulation bytes" etc. The SPS and SEI NALUs seem to be properly stripped of any emulation bytes. I can manually add a call to strip a copy of the NALU header, but I was curious if there's an elegant way someone else has already thought about. Thanks, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Aug 17 20:49:58 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 17 Aug 2013 20:49:58 -0700 Subject: [Live-devel] authorizing users In-Reply-To: References: <6179FC13-4CEA-41E0-81E5-9FA86501F4C8@live555.com> Message-ID: <19E26A31-7F58-479B-A3BE-F2F5C5132A92@live555.com> > In our case, each stream will have different set of username-passwd combination. In other words, username/passwd combination of ?Stream-1? should not be allowed to access ?Stream-2?, and so on. In our case, username could be same across streams, as they are derived from the cameras whose streams are being proxy-ed. That's ridiculous. What happens if two different 'back end' streams happen to have the same username *and* password? I've never heard of *any* access control mechanism that allows two different users to use the same username, but with different passwords. Providing such a system would not only weaken security, it would also cause confusion, because noone is going to expect this. But it's a moot point, because we don't (can't) support this, even if you reimplement "specialClientUserAccessCheck()", because our RTSP server code assumes that each username has one - and only one - password. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Aug 17 21:26:54 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 17 Aug 2013 21:26:54 -0700 Subject: [Live-devel] emulation bytes in a slice NALU In-Reply-To: <274F7B50569A1B4C9D7BCAB17A9C7BE10713B9DF@mailguy3.skynet.nuvation.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE10713B9DF@mailguy3.skynet.nuvation.com> Message-ID: <316124EC-E6B0-4751-9C50-24E7F4EB0C7A@live555.com> > I am curious if someone could shed some light on the following assumption in the live555 code: > > liveMedia/H264VideoStreamFramer.cpp:524: // Note: We assume that there aren't any 'emulation prevention' bytes here to worry about... What this means is that we 'hope' that there aren't any 'emulation prevention' bytes to worry about, because our code doesn't check for them in this case. (Our H.264 parsing code checks for/removes 'emulation prevention' bytes only when parsing SPS or PPS NAL units, because those are the only NAL units whose contents we really care about, and because doing so for other, much larger NAL units would be costly.) As you noted, our "analyze_slice_header()" function doesn't check for/remove 'emulation prevention' bytes in VCL NAL units (the ones that have slice headers). That's probably OK, because we call "analyze_slice_header()" only in certain cases, to check the parameters of the 'current' and 'next' NAL units' slice headers to try to figure out whether the 'current' NAL unit ends an 'access unit' (basically, a 'frame'). Our code probably ends up doing the right thing even for your stream. But this turns out to be a moot point, because the "H264VideoStreamFramer" code will shortly be changed to make this 'end of access unit' check more accurate (and more efficient). As part of this, the "analyze_slice_header()" function will probably be removed entirely. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at nomadsystems.com.au Mon Aug 19 03:33:09 2013 From: julien at nomadsystems.com.au (julien@nomadsystems) Date: Mon, 19 Aug 2013 12:33:09 +0200 Subject: [Live-devel] Open RTSP and video file splitting... Message-ID: <5211F465.7030405@nomadsystems.com.au> Hi, I'm trying to do exactly what Matteo Lisi has tried to do a few years back ( 20th Dec 2010 - Under the same post title, but different thread ). I need to split an RTSP feed into multiple files of 30 seconds. I have done what has been suggested in the thread by sub-classing "QuickTimeFileSink" and in the "QuickTimeFileSink::afterGettingFrame" ( after sync point ) re-open a new file without stopping the RTSP session. I indeed get the data into multiple files of 30 seconds, BUT the stream doesn't seem to be in the right spot to re-start the new files. So in consequence only the first file is playable. Do you have any suggestion(s) to help me resolve this issue please ? Cheers, Julien Sni From Philipp.Schrader at nuvation.com Mon Aug 19 09:38:34 2013 From: Philipp.Schrader at nuvation.com (Philipp Schrader) Date: Mon, 19 Aug 2013 09:38:34 -0700 Subject: [Live-devel] emulation bytes in a slice NALU In-Reply-To: <316124EC-E6B0-4751-9C50-24E7F4EB0C7A@live555.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE10713B9DF@mailguy3.skynet.nuvation.com> <316124EC-E6B0-4751-9C50-24E7F4EB0C7A@live555.com> Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE10713BADB@mailguy3.skynet.nuvation.com> As you noted, our "analyze_slice_header()" function doesn't check for/remove 'emulation prevention' bytes in VCL NAL units (the ones that have slice headers). That's probably OK, because we call "analyze_slice_header()" only in certain cases, to check the parameters of the 'current' and 'next' NAL units' slice headers to try to figure out whether the 'current' NAL unit ends an 'access unit' (basically, a 'frame'). Our code probably ends up doing the right thing even for your stream. But this turns out to be a moot point, because the "H264VideoStreamFramer" code will shortly be changed to make this 'end of access unit' check more accurate (and more efficient). As part of this, the "analyze_slice_header()" function will probably be removed entirely. Fair enough. I'm looking forward to the upcoming releases. Until then I will keep the hack that strips the emulation bytes to get rid of the erroneous 'end of access units' it was producing and thus delaying the video stream. Thanks, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 19 12:21:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Aug 2013 12:21:05 -0700 Subject: [Live-devel] emulation bytes in a slice NALU In-Reply-To: <274F7B50569A1B4C9D7BCAB17A9C7BE10713BADB@mailguy3.skynet.nuvation.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE10713B9DF@mailguy3.skynet.nuvation.com> <316124EC-E6B0-4751-9C50-24E7F4EB0C7A@live555.com> <274F7B50569A1B4C9D7BCAB17A9C7BE10713BADB@mailguy3.skynet.nuvation.com> Message-ID: <3B6E3CB2-E706-4A79-AC95-0472BF227CE8@live555.com> > Fair enough. I?m looking forward to the upcoming releases. > Until then I will keep the hack that strips the emulation bytes to get rid of the erroneous ?end of access units? it was producing and thus delaying the video stream. Could you post (on a web site, unless it's small) an example of a ".264" file that causes this problem for you? I'd like to use it for testing. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglan at yahoo.com Mon Aug 19 07:17:43 2013 From: zanglan at yahoo.com (Lan Zang) Date: Mon, 19 Aug 2013 22:17:43 +0800 (SGT) Subject: [Live-devel] The Speex over RTP Message-ID: <1376921863.6269.YahooMailNeo@web195304.mail.sg3.yahoo.com> Hi, I am trying to send out the speex encoded audio data via RTP. I read the mail you sent long time ago. Since speex over RTP requires no extra headers, so, I used SimpleRTPSink as the sink class. However?the player (I am using ffmpeg/ffplay) can not play the video properly. It complains about multiple frames in the RTP packet. I googled around and I found that the speex over RTP (RFC5574) reqiures that the single speex frame, which is 38 octets long when using 8k sample rate and default quality, can not be broken into 2 RTP packets. So, I wonder if there is any method in SimpleRTPSink to control the single frame kept in the same RTP packet? Or I just need to write a new classed derived from MultiFramedRTPSink and rewrite the method?afterGettingFrame1()? Regards, Lan Zang(Sander) -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 20 01:59:58 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Aug 2013 01:59:58 -0700 Subject: [Live-devel] The Speex over RTP In-Reply-To: <1376921863.6269.YahooMailNeo@web195304.mail.sg3.yahoo.com> References: <1376921863.6269.YahooMailNeo@web195304.mail.sg3.yahoo.com> Message-ID: > I am trying to send out the speex encoded audio data via RTP. I read the mail you sent long time ago. Since speex over RTP requires no extra headers, so, I used SimpleRTPSink as the sink class. > However the player (I am using ffmpeg/ffplay) can not play the video properly. It complains about multiple frames in the RTP packet. I googled around and I found that the speex over RTP (RFC5574) reqiures that the single speex frame, which is 38 octets long when using 8k sample rate and default quality, can not be broken into 2 RTP packets. So, I wonder if there is any method in SimpleRTPSink to control the single frame kept in the same RTP packet? Yes. Note the (optional) parameter "allowMultipleFramesPerPacket" to "SimpleRTPSink::createNew()". By default, it's True, but if you instead set it to False, you'll get only one frame in each outgoing RTP packet. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at nomadsystems.com.au Tue Aug 20 04:05:44 2013 From: julien at nomadsystems.com.au (julien@nomadsystems) Date: Tue, 20 Aug 2013 13:05:44 +0200 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <5211F465.7030405@nomadsystems.com.au> References: <5211F465.7030405@nomadsystems.com.au> Message-ID: <52134D88.3020208@nomadsystems.com.au> > I need to split an RTSP feed into multiple files of 30 seconds. I have > done > what has been suggested in the thread by sub-classing "QuickTimeFileSink" > and in the "QuickTimeFileSink::afterGettingFrame" ( after sync point ) > re-open a new file without stopping the RTSP session. > > I indeed get the data into multiple files of 30 seconds, BUT the stream > doesn't seem to be in the right spot to re-start the new files. So in > consequence only the first file is playable. Snippet Regarding the un-playable file I feel a bit silly , but it was just missing the re-initialization of the "fHaveCompletedOutputFile = false" to write the footer and voila. Having said that, I still have the problem of not starting the next files at the right spot I believe. When I play them I have a few seconds where nothing moves before to pick up what I suppose is a key frame. So in "QuickTimeFileSink::afterGettingFrame" this is what I do : Snippet Snippet void QuickTimeFileSink ::afterGettingFrame(void* clientData,unsigned packetDataSize, unsigned /*numTruncatedBytes*/, struct timeval presentationTime, unsigned /*durationInMicroseconds*/) { SubsessionIOState* ioState = (SubsessionIOState*)clientData; if (!ioState->syncOK(presentationTime)) { // Ignore this data: ioState->fOurSink.continuePlaying(); return; } // [my-code] Boolean keyFrame = (ioState->fBuffer && *(ioState->fBuffer->dataStart()) == H264_IDR_FRAME); ioState->fOurSink.afterGettingFrame1( packetDataSize, presentationTime, keyFrame); // [/my-code] ioState->afterGettingFrame(packetDataSize, presentationTime); } "afterGettingFrame1" is the handler in my subclassed QuickTimeFileSink class I use to do the file close/re-open when the "keyFrame = true" and the 30 seconds elapsed. But for some reasons, this doesn't work. Any ideas why ? Many thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 20 08:18:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Aug 2013 08:18:07 -0700 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <52134D88.3020208@nomadsystems.com.au> References: <5211F465.7030405@nomadsystems.com.au> <52134D88.3020208@nomadsystems.com.au> Message-ID: <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> Rather than modifying the supplied library code - which is unlikely to get you any support on this mailing list - why not instead keep the code 'as is', but instead use a separate "QuickTimeFileSink" object for each segment of the stream. I.e., every 30 seconds do: Medium::close(mySinkObject); mySinkObject = QuickTimeFileSink::createNew( ... ); mySinkObject->startPlaying(theSameSourceAsBefore, ... ); Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at nomadsystems.com.au Tue Aug 20 09:21:57 2013 From: julien at nomadsystems.com.au (julien@nomadsystems) Date: Tue, 20 Aug 2013 18:21:57 +0200 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> References: <5211F465.7030405@nomadsystems.com.au> <52134D88.3020208@nomadsystems.com.au> <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> Message-ID: <521397A5.4000108@nomadsystems.com.au> But closing and re-opening the RTSP stream will create a gap between the files. Anyhow, I just tested your suggestion and unfortunately it doesn't solve my problem of having the start of file not being aligned on a KeyFrame. In other words the video remains still until it finds a full frame to refresh and from there on it starts playing properly. Is there any options I haven't seen to fix this using the library 'as is' ? Regards On Tuesday, 20 August 2013 5:18:07 PM, Ross Finlayson wrote: > Rather than modifying the supplied library code - which is unlikely to > get you any support on this mailing list - why not instead keep the > code 'as is', but instead use a separate "QuickTimeFileSink" object > for each segment of the stream. > > I.e., every 30 seconds do: > > Medium::close(mySinkObject); > mySinkObject = QuickTimeFileSink::createNew( ... ); > mySinkObject->startPlaying(theSameSourceAsBefore, ... ); > > > 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 Aug 20 12:00:32 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Aug 2013 12:00:32 -0700 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <521397A5.4000108@nomadsystems.com.au> References: <5211F465.7030405@nomadsystems.com.au> <52134D88.3020208@nomadsystems.com.au> <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> <521397A5.4000108@nomadsystems.com.au> Message-ID: <2D712BB2-462E-45F1-977D-DE4EB6F8CD35@live555.com> > But closing and re-opening the RTSP stream will create a gap between the files. I didn't suggest "closing and reopening the RTSP stream". My suggestion was to keep the RTSP stream open, but close just the "QuickTimeFileSink" object, then create a new one and call "startPlaying()" on it - from the existing source. This doesn't involve any RTSP commands at all. > Anyhow, I just tested your suggestion and unfortunately it doesn't solve my > problem of having the start of file not being aligned on a KeyFrame. It sounds like you're trying to do something that the "QuickTimeFileSink" code was never intended to do - namely, detailed editing on the output file. Your best solution then is probably just to record a single file for the entire stream, and then later - using some separate tool that's intended specifically for editing '.mov'/'.mp4' files - break it apart into separate files of whatever length you want. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at nomadsystems.com.au Tue Aug 20 13:06:21 2013 From: julien at nomadsystems.com.au (julien@nomadsystems) Date: Tue, 20 Aug 2013 22:06:21 +0200 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <2D712BB2-462E-45F1-977D-DE4EB6F8CD35@live555.com> References: <5211F465.7030405@nomadsystems.com.au> <52134D88.3020208@nomadsystems.com.au> <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> <521397A5.4000108@nomadsystems.com.au> <2D712BB2-462E-45F1-977D-DE4EB6F8CD35@live555.com> Message-ID: <5213CC3D.7030904@nomadsystems.com.au> > I didn't suggest "closing and reopening the RTSP stream". My > suggestion was to keep the RTSP stream open, but close just the > "QuickTimeFileSink" object, then create a new one and call > "startPlaying()" on it - from the existing source. This doesn't > involve any RTSP commands at all. My bad, I was under the impression that QuickTimeFileSink object was tightly bound with the RTSP control object. > It sounds like you're trying to do something that the > "QuickTimeFileSink" code was never intended to do - namely, detailed > editing on the output file. > > Your best solution then is probably just to record a single file for > the entire stream, and then later - using some separate tool that's > intended specifically for editing '.mov'/'.mp4' files - break it apart > into separate files of whatever length you want. Fair enough, but unfortunately I cannot record a single file as I need to be feeding real-time ( actually a delayed stream of .. X seconds ) the Microsoft Expression Encoder. Last question and I understand this is clearly not something you support or even appreciate; but what would be the way to do a QuickTimeFileSink sink alike class that supports multi-file output handling the way I need it ? In any case thanks for all these feedback so far, it's greatly appreciated. From Alexc at optibase.com Tue Aug 20 13:29:55 2013 From: Alexc at optibase.com (Alex Chernilov) Date: Tue, 20 Aug 2013 23:29:55 +0300 Subject: [Live-devel] TS Mux data sync. Message-ID: Hi all, I'm very new to Live555, so it seems that I'm missing something very basic. I'm trying to mux a H264 elementary stream along with the private data into MPEG TS. It should be done offline, with 2 files - video and data. I've added the support for data in the MPEG2TransportStreamMultiplexor ( PMT and other stuff ), and this works. The problem is that I only get data packets inserted in the resulted file until the first video packet (something like 5 packets). After that, only video packets are present. If I disable video input, all data packets are present, with correct PTSs. This is how I tried to do it: 1. Created a H264VideoStreamFramer 2. Created a DataStreamFramer (based on the FramedFilter) 3. Created a MyStreamFromESSource (based on Mux, so I could add not only video and audio) 4. Added Video and Data sources ( addNewVideoSource, addNewDataSource) 5. In my DataStreamFramer, I implemented a parser which extracts a timing info from the data and aligns it with the "wall clock". What am I doing wrong? Thanks, Alex ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 20 14:54:49 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Aug 2013 14:54:49 -0700 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <5213CC3D.7030904@nomadsystems.com.au> References: <5211F465.7030405@nomadsystems.com.au> <52134D88.3020208@nomadsystems.com.au> <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> <521397A5.4000108@nomadsystems.com.au> <2D712BB2-462E-45F1-977D-DE4EB6F8CD35@live555.com> <5213CC3D.7030904@nomadsystems.com.au> Message-ID: <2065AEE7-EE07-48AA-AA9F-97A956AE651B@live555.com> >> Your best solution then is probably just to record a single file for >> the entire stream, and then later - using some separate tool that's >> intended specifically for editing '.mov'/'.mp4' files - break it apart >> into separate files of whatever length you want. > > Fair enough, but unfortunately I cannot record a single file as I need > to be feeding real-time ( actually a delayed stream of .. X seconds ) > the Microsoft Expression Encoder. > > Last question and I understand this is clearly not something you support > or even appreciate; but what would be the way to do a QuickTimeFileSink > sink alike class that supports multi-file output handling the way I need it ? If your input stream is H.264 video only (i.e., with no audio), then another solution would be to write your own "MediaSink" subclass (perhaps similar to the existing "H264VideoFileSink" class) that writes a sequence of raw (i.e., elementary stream) H.264 video files. You should be able to easily ensure that each output file begins with a 'key frame'. You could then, concurrently, process each of these output raw H.264 video files into '.mov'/'.mp4' files to feed into your Microsoft whatever (or just feed the raw H.264 files into your Microsoft whatever, if it can handle those). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 20 17:28:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Aug 2013 17:28:15 -0700 Subject: [Live-devel] TS Mux data sync. In-Reply-To: References: Message-ID: <5D9C874F-1D2E-4D52-9F70-A0FEA4F08940@live555.com> > I?m trying to mux a H264 elementary stream along with the private data into MPEG TS. It should be done offline, with 2 files ? video and data. I?ve added the support for data in the MPEG2TransportStreamMultiplexor ( PMT and other stuff ), and this works. The problem is that I only get data packets inserted in the resulted file until the first video packet (something like 5 packets). After that, only video packets are present. I think the problem you're facing is that our Transport Stream multiplexing code inserts chunks of data - from each source - as soon as it gets them, regardless of how the chunks of data is timestamped. I.e., it *doesn't* use the timestamps to make sure that all of the chunks of data get inserted into the Transport Stream in timestamp order. The reason for this is that the code was intended to multiplex live sources, or data from a single file only (as we do with our "testH264VideoToTransportStream" demo application). Your solution, therefore, is to (somehow) make your data sources 'live' streams, delivering data to their downstream object (in this case, the Transport Stream multiplexor) only at the appropriate time, rather than immediately. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at nomadsystems.com.au Wed Aug 21 06:55:32 2013 From: julien at nomadsystems.com.au (julien@nomadsystems) Date: Wed, 21 Aug 2013 15:55:32 +0200 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <2065AEE7-EE07-48AA-AA9F-97A956AE651B@live555.com> References: <5211F465.7030405@nomadsystems.com.au> <52134D88.3020208@nomadsystems.com.au> <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> <521397A5.4000108@nomadsystems.com.au> <2D712BB2-462E-45F1-977D-DE4EB6F8CD35@live555.com> <5213CC3D.7030904@nomadsystems.com.au> <2065AEE7-EE07-48AA-AA9F-97A956AE651B@live555.com> Message-ID: <5214C6D4.7050601@nomadsystems.com.au> > If your input stream is H.264 video only (i.e., with no audio), then > another solution would be to write your own "MediaSink" subclass > (perhaps similar to the existing "H264VideoFileSink" class) that > writes a sequence of raw (i.e., elementary stream) H.264 video files. > You should be able to easily ensure that each output file begins with > a 'key frame'. You could then, concurrently, process each of these > output raw H.264 video files into '.mov'/'.mp4' files to feed into > your Microsoft whatever (or just feed the raw H.264 files into your > Microsoft whatever, if it can handle those). Much much better, it looks a lot more fluid now.. The trouble I have now is the play speed. It's as if there was no clock leading the speed of playback and my 30 seconds of video goes as fast as it can. I suppose that embedding my stream in an avi/wmv container should fix this ? Feels good to see some progress though :) Thank, Julien From Alexc at optibase.com Wed Aug 21 07:17:49 2013 From: Alexc at optibase.com (Alex Chernilov) Date: Wed, 21 Aug 2013 17:17:49 +0300 Subject: [Live-devel] TS Mux data sync. References: <5D9C874F-1D2E-4D52-9F70-A0FEA4F08940@live555.com> Message-ID: Ross, Thanks a lot! I could've been looking for this sync for ages! Is it possible to have a Mux process a "Master" Pid (video) and periodically set an event trigger (providing the current timing)? The other DataStreamFramer should wait for this event and deliver its data when it arrives. I could not figure out how to start the Framer idle and provide one frame on request... Thanks, Alex From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, August 21, 2013 3:28 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] TS Mux data sync. I'm trying to mux a H264 elementary stream along with the private data into MPEG TS. It should be done offline, with 2 files - video and data. I've added the support for data in the MPEG2TransportStreamMultiplexor ( PMT and other stuff ), and this works. The problem is that I only get data packets inserted in the resulted file until the first video packet (something like 5 packets). After that, only video packets are present. I think the problem you're facing is that our Transport Stream multiplexing code inserts chunks of data - from each source - as soon as it gets them, regardless of how the chunks of data is timestamped. I.e., it *doesn't* use the timestamps to make sure that all of the chunks of data get inserted into the Transport Stream in timestamp order. The reason for this is that the code was intended to multiplex live sources, or data from a single file only (as we do with our "testH264VideoToTransportStream" demo application). Your solution, therefore, is to (somehow) make your data sources 'live' streams, delivering data to their downstream object (in this case, the Transport Stream multiplexor) only at the appropriate time, rather than immediately. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ************************************************************************ ************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************ ************ = ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at nomadsystems.com.au Wed Aug 21 07:32:49 2013 From: julien at nomadsystems.com.au (julien@nomadsystems) Date: Wed, 21 Aug 2013 16:32:49 +0200 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <5214C6D4.7050601@nomadsystems.com.au> References: <5211F465.7030405@nomadsystems.com.au> <52134D88.3020208@nomadsystems.com.au> <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> <521397A5.4000108@nomadsystems.com.au> <2D712BB2-462E-45F1-977D-DE4EB6F8CD35@live555.com> <5213CC3D.7030904@nomadsystems.com.au> <2065AEE7-EE07-48AA-AA9F-97A956AE651B@live555.com> <5214C6D4.7050601@nomadsystems.com.au> Message-ID: <5214CF91.5010704@nomadsystems.com.au> > I suppose that embedding my stream in an avi/wmv container should fix > this ? It does ! And it is actually an easy job with the tool named avc2avi :) Thank you so much for your help Ross, much appreciated ! Julien From finlayson at live555.com Wed Aug 21 08:07:23 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 21 Aug 2013 08:07:23 -0700 Subject: [Live-devel] Open RTSP and video file splitting... In-Reply-To: <5214C6D4.7050601@nomadsystems.com.au> References: <5211F465.7030405@nomadsystems.com.au> <52134D88.3020208@nomadsystems.com.au> <8EFD277A-0D87-4FEC-9F54-4A6F73D4A786@live555.com> <521397A5.4000108@nomadsystems.com.au> <2D712BB2-462E-45F1-977D-DE4EB6F8CD35@live555.com> <5213CC3D.7030904@nomadsystems.com.au> <2065AEE7-EE07-48AA-AA9F-97A956AE651B@live555.com> <5214C6D4.7050601@nomadsystems.com.au> Message-ID: <2A83083E-FDCF-47A0-A035-64E498B32C79@live555.com> >> If your input stream is H.264 video only (i.e., with no audio), then >> another solution would be to write your own "MediaSink" subclass >> (perhaps similar to the existing "H264VideoFileSink" class) that >> writes a sequence of raw (i.e., elementary stream) H.264 video files. >> You should be able to easily ensure that each output file begins with >> a 'key frame'. You could then, concurrently, process each of these >> output raw H.264 video files into '.mov'/'.mp4' files to feed into >> your Microsoft whatever (or just feed the raw H.264 files into your >> Microsoft whatever, if it can handle those). > > Much much better, it looks a lot more fluid now.. > The trouble I have now is the play speed. It's as if there was no clock leading the speed of playback and my 30 seconds of video goes as fast as it can. Try keeping track of SPS and PPS NAL units, and insert one of each at the start of each output file (i.e., each of your 30-second segments). That will probably give your conversion/editing software the timing information it needs. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Philipp.Schrader at nuvation.com Wed Aug 21 11:41:09 2013 From: Philipp.Schrader at nuvation.com (Philipp Schrader) Date: Wed, 21 Aug 2013 11:41:09 -0700 Subject: [Live-devel] emulation bytes in a slice NALU In-Reply-To: <3B6E3CB2-E706-4A79-AC95-0472BF227CE8@live555.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE10713B9DF@mailguy3.skynet.nuvation.com> <316124EC-E6B0-4751-9C50-24E7F4EB0C7A@live555.com> <274F7B50569A1B4C9D7BCAB17A9C7BE10713BADB@mailguy3.skynet.nuvation.com> <3B6E3CB2-E706-4A79-AC95-0472BF227CE8@live555.com> Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE10713C283@mailguy3.skynet.nuvation.com> Could you post (on a web site, unless it's small) an example of a ".264" file that causes this problem for you? I'd like to use it for testing. Let me know if the following link works for you: https://www.dropbox.com/s/s365ky5hqhko1x0/H264_Problem_sample_10sec.264 It's a 10 second snippet of a test video that we use. Since the problem starts on the 511th IDR frame and I don't want to post that whole file, this clip starts at IDR frame 509 and stops right before IDR frame 529. In other words, the first second (i.e. IDR frames 509 and 510) everything looks good. In IDR frame 511 slice 2 (zero-indexed) you'll notice the byte sequence "25 00 1f e2 22 00 00 03 02 00 00 80 ab ff ed 5f". Here the "03" needs to be stripped. This escape sequence will occur in all subsequent IDR frames on the third slice (i.e. slice 2 if zero-indexed). If you image this data being produced by a live source, then live555 (with the current code) will slow the stream down every time it sees an IDR frame until the escape sequence disappears from the encoded data. Please let me know if I misunderstood something about live555's operation here. Hope this helps, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericpronovost at gmail.com Wed Aug 21 08:57:32 2013 From: ericpronovost at gmail.com (Eric Pronovost) Date: Wed, 21 Aug 2013 11:57:32 -0400 Subject: [Live-devel] RRHandlerRecord leak Message-ID: There seem to be a memory leak in RTCP.cpp. In function setSpecificRRHandler(), I changed last line from fSpecificRRHandlerTable->Add(fromAddress, (~0), fromPort, rrHandler); to RRHandlerRecord* pOld = (RRHandlerRecord*)fSpecificRRHandlerTable->Add(fromAddress, (~0), fromPort, rrHandler); if (pOld) delete pOld; (hope this is correct, this is my first post to live-devel) Eric Pronovost -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Aug 22 09:30:09 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 22 Aug 2013 18:30:09 +0200 Subject: [Live-devel] RTSP server reclarmation time Message-ID: <31777_1377189010_52163C92_31777_186_3_1BE8971B6CFF3A4F97AF4011882AA2550156381C1E45@THSONEA01CMS01P.one.grp> Hi Ross, We use the reclamationTestSeconds argument of the RTSPServer, but this information doesnot seem to be sent to the RTSP client. The RTSP SETUP answer always answer with "Session:", without timeout value. As some video player use this argument to do keepAlive on RTSP, it could be nice to notify the timeout in order to trig their RTSP keepAlive task. You will find attached the patch I tried. Do you think it could be an evolution in the RTSP Server ? Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTSPServer.patch Type: application/octet-stream Size: 2912 bytes Desc: RTSPServer.patch URL: From finlayson at live555.com Thu Aug 22 13:16:40 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Aug 2013 13:16:40 -0700 Subject: [Live-devel] RTSP server reclarmation time In-Reply-To: <31777_1377189010_52163C92_31777_186_3_1BE8971B6CFF3A4F97AF4011882AA2550156381C1E45@THSONEA01CMS01P.one.grp> References: <31777_1377189010_52163C92_31777_186_3_1BE8971B6CFF3A4F97AF4011882AA2550156381C1E45@THSONEA01CMS01P.one.grp> Message-ID: > Do you think it could be an evolution in the RTSP Server ? No. http://lists.live555.com/pipermail/live-devel/2013-June/017061.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 22 14:42:38 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Aug 2013 14:42:38 -0700 Subject: [Live-devel] RRHandlerRecord leak In-Reply-To: References: Message-ID: <906495DD-9A39-4AF5-9E34-90B847A1374F@live555.com> Eric, Thanks for the report. Yes, this was a memory leak (albeit not a significant one, because it'll be unusual for "setSpecificRRHandler()" to be called more than once). It will be fixed in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From srimugunthan.dhandapani at gmail.com Thu Aug 22 02:23:39 2013 From: srimugunthan.dhandapani at gmail.com (srimugunthan dhandapani) Date: Thu, 22 Aug 2013 14:53:39 +0530 Subject: [Live-devel] a single application with RTSP client and server Message-ID: Hi, I want to develop a application that receives multiple streams from cameras and transcode it and re-export the transcoded streams to to different URLs . The transcode operation happens asynchronously. So the client and server run in different threads Before starting the RTSP client and server i need to initialise my transcoder. I think i will just make it work for single stream first by combining code from testRTSPClient.cpp and testOnDemandRTSPServer.cpp. The rough skeleton for what i need to accomplish is below: main() { InitialiseTxcoder(); startRTSPClient(URL1,URL2....); startRTSPServer(); } RTSPClient { afterGettingFrame() { InputTranscode(channelNum,fReceiveBuffer); } } RTSPServer { ReceiveSingleTranscodedFrame(&TxFrame, &channelNUM) ExportStream(TxFrame, channelNum) } 1. How do i run the Client and server as different threads from one single application? 2. Are there any example programs for this? Thanks in advance for the help, mugunthan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Fri Aug 23 01:26:24 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Fri, 23 Aug 2013 10:26:24 +0200 Subject: [Live-devel] RTSP server reclarmation time In-Reply-To: References: <31777_1377189010_52163C92_31777_186_3_1BE8971B6CFF3A4F97AF4011882AA2550156381C1E45@THSONEA01CMS01P.one.grp> Message-ID: <29990_1377246385_52171CB1_29990_6200_4_1BE8971B6CFF3A4F97AF4011882AA2550156381FB2D8@THSONEA01CMS01P.one.grp> Hi Ross, Thanks a lot for your quick support. But our situation is a bit different that the one described in the link. When a RTSP client ask for a PAUSE, the RTCP RR are no more send, and then the session after the reclamation timeout of the RTSPServer if no RTSP command are sent. Do you think that an RTCP Client should sent RTCP RR reports while it is paused ? Thanks & 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? : jeudi 22 ao?t 2013 22:17 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTSP server reclarmation time Do you think it could be an evolution in the RTSP Server ? No. http://lists.live555.com/pipermail/live-devel/2013-June/017061.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 23 01:59:10 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 23 Aug 2013 01:59:10 -0700 Subject: [Live-devel] RTSP server reclarmation time In-Reply-To: <29990_1377246385_52171CB1_29990_6200_4_1BE8971B6CFF3A4F97AF4011882AA2550156381FB2D8@THSONEA01CMS01P.one.grp> References: <31777_1377189010_52163C92_31777_186_3_1BE8971B6CFF3A4F97AF4011882AA2550156381C1E45@THSONEA01CMS01P.one.grp> <29990_1377246385_52171CB1_29990_6200_4_1BE8971B6CFF3A4F97AF4011882AA2550156381FB2D8@THSONEA01CMS01P.one.grp> Message-ID: <4650DCEB-8A38-41CB-8C37-012AD3C5CBA1@live555.com> > Do you think that an RTCP Client should sent RTCP RR reports while it is paused ? Yes. (And, FYI, our implementation will do this (because the "RTCPInstance" stays active and working, even when the stream is paused.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From timothy.c1.anderson at lmco.com Fri Aug 23 10:42:45 2013 From: timothy.c1.anderson at lmco.com (Anderson, Timothy C1) Date: Fri, 23 Aug 2013 17:42:45 +0000 Subject: [Live-devel] Request near live video playback for RTSP session Message-ID: I am trying to go to the end of an RTSP Stream and request to play from there on. Someone suggested that you can use "Range: npt=-1" to do this. It does not appear to work, however. SETUP rtsp://172.18.11.236:5501/testRecordingRome2.ts RTSP/1.0 CSeq: 1 Transport: RAW/RAW/UDP;unicast;destination=172.18.11.150;client_port=49152 Range: npt=-1 PLAY rtsp://172.18.11.236:5501/testRecordingRome2.ts RTSP/1.0 CSeq: 2 Session: D5C39A61 The video is still being written and recorded. I want to seek to the end and tell it to play from the very end and continue on from there. Is there a way I can do this? TIA, ---Tim--- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 23 11:16:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 23 Aug 2013 11:16:18 -0700 Subject: [Live-devel] Request near live video playback for RTSP session In-Reply-To: References: Message-ID: <7C896030-54F9-46EB-AC58-236CA6762947@live555.com> > The video is still being written and recorded. I want to seek to the end and tell it to play from the very end and continue on from there. > > Is there a way I can do this? Likely not. The RTSP standard *does* include a mechanism for requesting this - namely, asking for a range of "npt=now-" (*not* npt=-1-); however, our RTSP client software does not support this, and neither does our RTSP server software. (You haven't said whether you are using our software as a RTSP client, a RTSP server, or both; however, in neither case does it currently support this.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglan at yahoo.com Fri Aug 23 06:45:44 2013 From: zanglan at yahoo.com (Lan Zang) Date: Fri, 23 Aug 2013 21:45:44 +0800 (SGT) Subject: [Live-devel] How to add audio stream later? Message-ID: <1377265544.89297.YahooMailNeo@web195301.mail.sg3.yahoo.com> Hi, ? ?In my RTSP server, I create a ServerMediaSession with ServerMediaSubsession for H.264 video stream. Somehow, I need to turn audio on later while streaming. I can add a ServerMediaSubsession into the ServerMediaSession, so the ServerMediaSession has 2 sub-sessions. But in this case, the player client is not aware of that the audio is on now. Per my understanding, the RTSP server shall notify the client by sending ANNOUNCE command with new SDP payload. So, is there anyway to let RTSP to do so? Best Regards, Lan Zang(Sander) -------------- next part -------------- An HTML attachment was scrubbed... URL: From srimugunthan.dhandapani at gmail.com Fri Aug 23 08:48:47 2013 From: srimugunthan.dhandapani at gmail.com (srimugunthan dhandapani) Date: Fri, 23 Aug 2013 21:18:47 +0530 Subject: [Live-devel] a single application with RTSP client and server In-Reply-To: References: Message-ID: On Thu, Aug 22, 2013 at 2:53 PM, srimugunthan dhandapani wrote: > Hi, > I want to develop a application that receives multiple streams from cameras > and > transcode it and re-export the transcoded streams to to different URLs . > > The transcode operation happens asynchronously. So the client and server run > in different threads > Before starting the RTSP client and server i need to initialise my > transcoder. > > > I think i will just make it work for single stream first by combining code > from testRTSPClient.cpp and testOnDemandRTSPServer.cpp. > > The rough skeleton for what i need to accomplish is below: > > main() > { > InitialiseTxcoder(); > startRTSPClient(URL1,URL2....); > startRTSPServer(); > > } > > RTSPClient > { > afterGettingFrame() > { > InputTranscode(channelNum,fReceiveBuffer); > > } > } > > RTSPServer > { > > ReceiveSingleTranscodedFrame(&TxFrame, &channelNUM) > ExportStream(TxFrame, channelNum) > > } > > 1. How do i run the Client and server as different threads from one single > application? > 2. Are there any example programs for this? > > Thanks in advance for the help, > mugunthan After some more reading of the Live555 FAQs and archives, I think the ProxyServer implementation will be useful for my scenario. (Am i right about this?) I am thinking of making the following changes in ProxyServerMediaSubsession.cpp: . change afterGettingFrame() to input the frames to the transcoder . change createNewStreamSource() to a new FramedSource class that gets the Frames from the transcoder output. For this, I need to get the next frame from the transcoder output and give these frames as input source? How do I make this change? The proxiedURL stream has to wait till the (proxyURL stream + Transcoder) has started. How do i do this synchronisation? In the ProxyServer implementation are the clients and server running as different threads? Thanks, mugunthan From finlayson at live555.com Fri Aug 23 22:59:13 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 23 Aug 2013 22:59:13 -0700 Subject: [Live-devel] How to add audio stream later? In-Reply-To: <1377265544.89297.YahooMailNeo@web195301.mail.sg3.yahoo.com> References: <1377265544.89297.YahooMailNeo@web195301.mail.sg3.yahoo.com> Message-ID: > In my RTSP server, I create a ServerMediaSession with ServerMediaSubsession for H.264 video stream. Somehow, I need to turn audio on later while streaming. I can add a ServerMediaSubsession into the ServerMediaSession, so the ServerMediaSession has 2 sub-sessions. But in this case, the player client is not aware of that the audio is on now. Per my understanding, the RTSP server shall notify the client by sending ANNOUNCE command with new SDP payload. So, is there anyway to let RTSP to do so? No, not with our software (or any other software that I'm aware of). The "ANNOUNCE" RTSP command has always been optional, and is barely implemented by anyone. Our library allows a RTSP client to send an "ANNOUNCE" command to the server, but we do not support a server sending an "ANNOUNCE" command to the client, nor do we have any way for the client to handle such a command. Your best solution would be to create your "ServerMediaSession" initially with an audio "ServerMediaSubsession", even if the audio stream doesn't actually exist at first. Then later, if you wish, you can actually start streaming the audio, and clients should start playing it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.khare at samsung.com Mon Aug 26 22:26:34 2013 From: s.khare at samsung.com (Shailendra Khare) Date: Tue, 27 Aug 2013 05:26:34 +0000 (GMT) Subject: [Live-devel] CAS encrypted stream Message-ID: <0E.6E.21086.A883C125@epcpsbgx4.samsung.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201308271056551_R2OCEO92.gif Type: image/gif Size: 14036 bytes Desc: not available URL: From finlayson at live555.com Mon Aug 26 23:03:20 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 26 Aug 2013 23:03:20 -0700 Subject: [Live-devel] CAS encrypted stream In-Reply-To: <0E.6E.21086.A883C125@epcpsbgx4.samsung.com> References: <0E.6E.21086.A883C125@epcpsbgx4.samsung.com> Message-ID: > I am trying to use live 555 to stream an CAS encrypted stream and use trick play on VOD client. Encrypted stream has ECM,EMM and CA packets as compared to original streams. Also PCR is modified > as per new packets inserted. > > I am thinking of changing the index file created from clear stream. Change will be for PCR values and transport packet numbers. > Will this change suffice for the trick play support on VOD client or any other change also needs to be done ? Unfortunately I don't know anything about "CAS encryption" (which I presume is the system described here: http://en.wikipedia.org/wiki/Conditional_access ), so I probably can't give you a good answer. However, depending on what kind of 'trick play' you want to support, I'm not convinced that you would need to change the index file format. (If you were to change the index file format to your own proprietary format, then I wouldn't be able to help you on this mailing list.) Instead, you might be able to keep the index file format unchanged, but just change the mechanism that you use to *create* an index file. If the only type of 'trick play' that you want to do is 'seeking' (i.e., no 'fast forward' or 'reverse play'), then you might be able use the existing index file format, provided that the index file can point to 'clean points' within the (encrypted) TS file from which you can safely resume streaming, after seeking. (Note our function "MPEG2TransportStreamIndexFile::rewindToCleanPoint()", in "liveMedia/MPEG2TransportStreamIndexFile.cpp".) If, however, you also want to support 'fast forward' or 'reverse play', then I'm not sure that you could do this on an encrypted Transport Stream, even if you were to change the index file format. The reason for this is that our 'fast forward' and 'reverse play' implementations work by picking selected 'key frames' from the original Transport Stream, and creating a whole new Transport Stream - built from these 'key frames'. I just don't see how you could do this from an encrypted stream. But again, I don't know anything about "CAS encryption", so I'm sorry that I can't be of more help. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 28 01:43:32 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Aug 2013 01:43:32 -0700 Subject: [Live-devel] emulation bytes in a slice NALU In-Reply-To: <274F7B50569A1B4C9D7BCAB17A9C7BE10713C283@mailguy3.skynet.nuvation.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE10713B9DF@mailguy3.skynet.nuvation.com> <316124EC-E6B0-4751-9C50-24E7F4EB0C7A@live555.com> <274F7B50569A1B4C9D7BCAB17A9C7BE10713BADB@mailguy3.skynet.nuvation.com> <3B6E3CB2-E706-4A79-AC95-0472BF227CE8@live555.com> <274F7B50569A1B4C9D7BCAB17A9C7BE10713C283@mailguy3.skynet.nuvation.com> Message-ID: <847B1D4B-45D8-47B6-B741-94C90A599A2A@live555.com> FYI, I have now installed a new version of the "LIVE555 Streaming Media" code that updates "H264VideoStreamFramer" to improve the test for whether or not the current NAL unit ends an access unit. (As a consequence, it fixes the bug with emulation bytes that you noted.) Thanks again for the report. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Subhankar_Saha at mindtree.com Wed Aug 28 11:26:16 2013 From: Subhankar_Saha at mindtree.com (Subhankar Saha) Date: Wed, 28 Aug 2013 18:26:16 +0000 Subject: [Live-devel] Issue in ProxyServerMediaSession Message-ID: Helllo Ross, We are facing a crash with ProxyServerMediaSession code, regarding which we would appreciate your help. Scenario: - 32 backend cameras being proxy-ed, bitrate around ~500 Kbps from each - Connection to backend camera is in RTP over RTSP (TCP) mode - Each stream is accessed by 2 downstream clients (UDP mode) - Network bandwidth is often loaded, resulting in client not receiving data for good duration - As a result, if clients don't receive data for 10 seconds, they disconnect - At ProxyServerMediaSession, this results in calling 'closeStreamSource', whereby PAUSE command is being sent to backend camera - The backend cameras do not support PAUSE commands - After a timeout, downstream clients reattempt connection, which results in sending PLAY command to backend camera - However, backend camera is for some reason is unresponsive, or, there is a lot of data being handled - 'scheduleLivenessCommand' gets called, which sends OPTIONS command, for which no reply is received - So, next connections are reset, and a DESCRIBE is sent - This is where the crash happens (rather, this is the last print I see, no replay for DESCRIBE is received) OS is Windows. I will try to gather a stack trace somehow running in Debug mode tomorrow. But, would you have an idea where things could be going wrong? Does camera not supporting PAUSE command make any difference? Regards, Subhankar. ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 28 11:53:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Aug 2013 11:53:15 -0700 Subject: [Live-devel] Issue in ProxyServerMediaSession In-Reply-To: References: Message-ID: > OS is Windows. I will try to gather a stack trace somehow running in Debug mode tomorrow. But, would you have an idea where things could be going wrong? No, but a stack trace might be able to help. I assume that you are running the latest version of the code, and have not modified it (especially not any of the "ProxyServerMediaSession" code) at all. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Subhankar_Saha at mindtree.com Wed Aug 28 22:57:23 2013 From: Subhankar_Saha at mindtree.com (Subhankar Saha) Date: Thu, 29 Aug 2013 05:57:23 +0000 Subject: [Live-devel] Issue in ProxyServerMediaSession In-Reply-To: References: Message-ID: We were using the almost-latest version of source code - 2013.08.16. With this version, here is the stack trace: dsm.exe!SocketDescriptor::~SocketDescriptor() + 0xbb bytes C++ dsm.exe!SocketDescriptor::`scalar deleting destructor'() + 0x8 bytes C++ dsm.exe!SocketDescriptor::tcpReadHandler() + 0x3f bytes C++ dsm.exe!BasicTaskScheduler::SingleStep() + 0x475 bytes C++ dsm.exe!BasicTaskScheduler0::doEventLoop() + 0x1c bytes C++ I have now downloaded 2013.08.28 version of source code, and built the same with Debugging enabled. To build with debugging enabled, following changes were made to 'win32config': - Commented 'NODEBUG=1' - 'TOOLS32' changed to 'C:\Program Files\Microsoft Visual Studio 9.0\VC', corresponding to Visual Studio 2008 - Added '-DFD_SETSIZE=1024' to 'COMPILE_OPTS' - Changed 'LINK_OPTS_0' to link 'msvcrtd.lib' No other changes made to source code anywhere. Also modified a few things on our side so that we can use 'live555ProxyServer.exe' instead of ours built using 'ProxyServerMediaSession'. With this too, we get the crash. And here is the stack trace: > live555ProxyServer.exe!_Tables::getOurTables(UsageEnvironment & env={...}, bool createIfNotPresent=true) Line 98 + 0x3 bytes C++ live555ProxyServer.exe!socketHashTable(UsageEnvironment & env={...}, bool createIfNotPresent=true) Line 38 + 0xe bytes C++ live555ProxyServer.exe!removeSocketDescription(UsageEnvironment & env={...}, int sockNum=-572662307) Line 102 + 0xb bytes C++ live555ProxyServer.exe!SocketDescriptor::~SocketDescriptor() Line 361 + 0x13 bytes C++ live555ProxyServer.exe!SocketDescriptor::`scalar deleting destructor'() + 0xf bytes C++ live555ProxyServer.exe!SocketDescriptor::tcpReadHandler(SocketDescriptor * socketDescriptor=0x01df9090, int mask=2) Line 430 + 0x2b bytes C++ live555ProxyServer.exe!BasicTaskScheduler::SingleStep(unsigned int maxDelayTime=0) Line 163 + 0x16 bytes C++ live555ProxyServer.exe!BasicTaskScheduler0::doEventLoop(char * watchVariable=0x00000000) Line 81 C++ live555ProxyServer.exe!main(int argc=21, char * * argv=0x001f1314) Line 206 C++ live555ProxyServer.exe!__tmainCRTStartup() Line 582 + 0x19 bytes C live555ProxyServer.exe!mainCRTStartup() Line 399 C kernel32.dll!75b9ed6c() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!771b37eb() ntdll.dll!771b37be() In verbose enabled, I see lots & lots of following prints: "RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" Do let me know if you need further information, or, anything I can do to help. Regards, Subhankar. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, August 29, 2013 12:23 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Issue in ProxyServerMediaSession OS is Windows. I will try to gather a stack trace somehow running in Debug mode tomorrow. But, would you have an idea where things could be going wrong? No, but a stack trace might be able to help. I assume that you are running the latest version of the code, and have not modified it (especially not any of the "ProxyServerMediaSession" code) at all. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Aug 29 02:08:41 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 29 Aug 2013 11:08:41 +0200 Subject: [Live-devel] RTSP server reclarmation time In-Reply-To: <4650DCEB-8A38-41CB-8C37-012AD3C5CBA1@live555.com> References: <31777_1377189010_52163C92_31777_186_3_1BE8971B6CFF3A4F97AF4011882AA2550156381C1E45@THSONEA01CMS01P.one.grp> <29990_1377246385_52171CB1_29990_6200_4_1BE8971B6CFF3A4F97AF4011882AA2550156381FB2D8@THSONEA01CMS01P.one.grp> <4650DCEB-8A38-41CB-8C37-012AD3C5CBA1@live555.com> Message-ID: <25519_1377767323_521F0F9A_25519_2337_1_1BE8971B6CFF3A4F97AF4011882AA255015638319466@THSONEA01CMS01P.one.grp> Hi Ross, Thanks for the support. Yes we using your library for both side client and server. But the server side was using a reclamation timeout of 5s and the RR are sent with a period computed with a quite complex logic. The experience show that the RR are send each about 5-10 seconds. In RTSPServer the default value is 65 seconds, clearly 5 seconds is too low. Is there a particular reason for 65 seconds ? Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : vendredi 23 ao?t 2013 10:59 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTSP server reclarmation time Do you think that an RTCP Client should sent RTCP RR reports while it is paused ? Yes. (And, FYI, our implementation will do this (because the "RTCPInstance" stays active and working, even when the stream is paused.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 29 02:21:21 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Aug 2013 02:21:21 -0700 Subject: [Live-devel] RTSP server reclarmation time In-Reply-To: <25519_1377767323_521F0F9A_25519_2337_1_1BE8971B6CFF3A4F97AF4011882AA255015638319466@THSONEA01CMS01P.one.grp> References: <31777_1377189010_52163C92_31777_186_3_1BE8971B6CFF3A4F97AF4011882AA2550156381C1E45@THSONEA01CMS01P.one.grp> <29990_1377246385_52171CB1_29990_6200_4_1BE8971B6CFF3A4F97AF4011882AA2550156381FB2D8@THSONEA01CMS01P.one.grp> <4650DCEB-8A38-41CB-8C37-012AD3C5CBA1@live555.com> <25519_1377767323_521F0F9A_25519_2337_1_1BE8971B6CFF3A4F97AF4011882AA255015638319466@THSONEA01CMS01P.one.grp> Message-ID: > But the server side was using a reclamation timeout of 5s and the RR are sent with a period computed with a quite complex logic. > The experience show that the RR are send each about 5-10 seconds. > > In RTSPServer the default value is 65 seconds, clearly 5 seconds is too low. > Is there a particular reason for 65 seconds ? I don't understand what you're complaining/asking about here. Yes, a "reclamationTestSeconds" value of 5 (seconds) is ridiculously low. So, don't set it to such a low value! And yes, the default value of "reclamationTestSeconds" is 65 seconds. But so what? You weren't using the default value. You said that you were using a value of 5s, for some strange reason... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 29 02:44:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Aug 2013 02:44:07 -0700 Subject: [Live-devel] Issue in ProxyServerMediaSession In-Reply-To: References: Message-ID: <500F53B1-46FB-44F1-B681-8B7D14D38161@live555.com> I think I know what is happening (a "SocketDescriptor" object is getting deleted twice), but unfortunately I don't know why. (A bug like this was fixed in July, but if you're using a recent version of the code, then it appears that another bug remains.) Unfortunately, because noone else has reported this, you're probably going to have to track down this bug yourself. However, you also mentioned the following: > In verbose enabled, I see lots & lots of following prints: > ?RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" This suggests that your back-end servers (i.e., network cameras) may be implemented using our software, but using an old version. If you upgrade these cameras to use a recent version of our software, then it's possible that they may no longer trigger the bug that you are finding in the proxy server. Note that if the cameras are using our software, then the camera manufacturer is legally *required* - under the terms of the LGPL - to, upon request, upgrade them to use the latest version of the code, or else tell you how you can do this yourself. So, you should ask the camera manufacturer(s) to upgrade their software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Subhankar_Saha at mindtree.com Thu Aug 29 04:19:44 2013 From: Subhankar_Saha at mindtree.com (Subhankar Saha) Date: Thu, 29 Aug 2013 11:19:44 +0000 Subject: [Live-devel] Issue in ProxyServerMediaSession In-Reply-To: <500F53B1-46FB-44F1-B681-8B7D14D38161@live555.com> References: <500F53B1-46FB-44F1-B681-8B7D14D38161@live555.com> Message-ID: Thank you Ross for you reply. Unfortunately, we have no control over camera manufacturers. In many cases, we will not even know which camera has been used by users of our software. We can probably request cameras that we test against in-house to upgrade their software - but then, every camera manufacturer will need their own time for testing out new f/w before releasing the same for upgrade. We cannot wait that long. Moving forward, we need to find a solution to this problem, so we will invest time in tracking where the bug is. I have two questions in this regard: (a) Will it be beneficial to increase socket's 'receive' buffer size in 'createNewRTPSink' for the RTP source? (This used to be done in older version of openRTSP) (b) Since network cameras are live source of stream, they may not be "pausable". I think most do not support PAUSE command at all. In such a case, data will continue to come from the back-end server even though there is no downstream clients connected. So instead of sending "PAUSE" to backend server (network camera), can we disconnect the connection and start from beginning (send DESCRIBE, and wait for clients to connect)? If this sounds good, what do we need to change in 'ProxyServerMediaSession' code? Thank you for your assistance. Regards, Subhankar. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, August 29, 2013 3:14 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Issue in ProxyServerMediaSession I think I know what is happening (a "SocketDescriptor" object is getting deleted twice), but unfortunately I don't know why. (A bug like this was fixed in July, but if you're using a recent version of the code, then it appears that another bug remains.) Unfortunately, because noone else has reported this, you're probably going to have to track down this bug yourself. However, you also mentioned the following: In verbose enabled, I see lots & lots of following prints: "RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize" This suggests that your back-end servers (i.e., network cameras) may be implemented using our software, but using an old version. If you upgrade these cameras to use a recent version of our software, then it's possible that they may no longer trigger the bug that you are finding in the proxy server. Note that if the cameras are using our software, then the camera manufacturer is legally *required* - under the terms of the LGPL - to, upon request, upgrade them to use the latest version of the code, or else tell you how you can do this yourself. So, you should ask the camera manufacturer(s) to upgrade their software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 29 09:23:37 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Aug 2013 09:23:37 -0700 Subject: [Live-devel] Issue in ProxyServerMediaSession In-Reply-To: References: <500F53B1-46FB-44F1-B681-8B7D14D38161@live555.com> Message-ID: <74EC6811-37C1-4ACD-92E0-1A1D3D4EC2B3@live555.com> > (a) Will it be beneficial to increase socket?s ?receive? buffer size in ?createNewRTPSink? for the RTP source? It might alleviate the problem, but probably wouldn't solve it. (However, you wouldn't do this in "createNewRTPSink()", because that's used for creating sockets that transmit (to front-end clients).) > (b) Since network cameras are live source of stream, they may not be ?pausable?. I think most do not support PAUSE command at all. That's not a problem. The proxy sends "PAUSE" commands only as a hint. In any case, I don't have time to speculate back and forth on this mailing list (for free) about this problem. Right now, because you're the only person encountering this, you're going to have to track it down yourself. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Subhankar_Saha at mindtree.com Fri Aug 30 12:38:21 2013 From: Subhankar_Saha at mindtree.com (Subhankar Saha) Date: Fri, 30 Aug 2013 19:38:21 +0000 Subject: [Live-devel] Issue in ProxyServerMediaSession In-Reply-To: <74EC6811-37C1-4ACD-92E0-1A1D3D4EC2B3@live555.com> References: <500F53B1-46FB-44F1-B681-8B7D14D38161@live555.com> <74EC6811-37C1-4ACD-92E0-1A1D3D4EC2B3@live555.com> Message-ID: In any case, I don't have time to speculate back and forth on this mailing list (for free) about this problem. Right now, because you're the only person encountering this, you're going to have to track it down yourself. Sorry. Here is what I found: #1. When the backend server goes away unceremoniously, the 'readSocket()' in 'SocketDescriptor::tcpReadHandler1()' will set 'fDeleteMyselfNext' - this causes 'SocketDescriptor::tcpReadHandler()' to delete the 'socketDescriptor'. Note that 'fAreInReadHandlerLoop' reset back to False before deleting the 'socketDescriptor' #2. 'SocketDescriptor::~SocketDescriptor()' then invokes RTSPClient's 'fServerRequestAlternativeByteHandler' with 0xFF (ReadErrorOccured) #3. For ProxyServerMediaSession, this results in negative return for OPTIONS command sent during Liveness. #4. 'continueAfterLivenessCommand' gets invoked, and thereby everything is being reset. #5. As part of those reset handling RTCPInstances gets closed - which results in deregistering from RTPInterface. #6. 'SocketDescriptor::deregisterRTPInterface' will then remove the reference of the SocketDescriptor from 'fSubChannelHasTable' - and once this is empty, and since 'fAreInReadHandlerLoop' is False (refer #1 above), this will go on to delete 'socketDescriptor' yet again. This deletion is successfully completed - resulting in successful 'removeSocketDescription()'. #7. After all clean-up, the 'fServerRequestAlternativeByteHandler' (from #2 above) finally returns back to the SocketDescriptor destructor, and it crashes in next call to 'removeSocketDescription'. SocketDescriptor is no longer a valid object at this point - it is already been deleted in #6. Any of the following seems to work for my use case: - Moving invocation of 'fServerRequestAlternativeByteHandler' to bottom of 'SocketDescriptor::~SocketDescriptor()' - Moving 'socketDescriptor->fAreInReadHandlerLoop = False;' to bottom of 'SocketDescriptor::tcpReadHandler()' Many thanks, Subhankar. ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Aug 31 02:17:25 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 31 Aug 2013 02:17:25 -0700 Subject: [Live-devel] Issue in ProxyServerMediaSession In-Reply-To: References: <500F53B1-46FB-44F1-B681-8B7D14D38161@live555.com> <74EC6811-37C1-4ACD-92E0-1A1D3D4EC2B3@live555.com> Message-ID: Subhankar, Thanks for the excellent work in tracking down this bug. I've now installed a new version - 2013.08.31 - of the code that includes your second suggested fix: " Moving ?socketDescriptor->fAreInReadHandlerLoop = False;? to bottom of ?SocketDescriptor::tcpReadHandler()?". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 501861472 at qq.com Sat Aug 31 18:40:31 2013 From: 501861472 at qq.com (=?gb18030?B?u8a8zMCl?=) Date: Sun, 1 Sep 2013 09:40:31 +0800 Subject: [Live-devel] for help Message-ID: this is the firs time I use live555.I use testRTSPClient as a demo in my object , now there is running well, but how could I shut it down ? Now i just use the function of shutdownStream, but there is memory leaks as follow:Detected memory leaks! Dumping objects -> {1023} normal block at 0x00ACEC18, 32 bytes long. Data: 78 B2 07 10 1C F3 3C 00 1C F3 3C 00 00 00 00 00 {203} normal block at 0x00AC9118, 1024 bytes long. Data: < < > 0C B1 07 10 00 00 00 00 00 00 00 00 18 F3 3C 00 {201} normal block at 0x003CF7A0, 32 bytes long. Data: < > D4 B2 07 10 C8 B2 07 10 FF FF FF FF 00 00 00 00 {200} normal block at 0x003CF318, 1100 bytes long. Data: < > EC B1 07 10 AC B0 07 10 18 EC AC 00 18 EC AC 00 In my object I need to open RTSPClient and shut down it frequently, I can not bear any memory leaks , so I need some advice . Thank you Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: