From finlayson at live555.com Wed Sep 1 00:49:59 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Sep 2010 00:49:59 -0700 Subject: [Live-devel] Set max connection number In-Reply-To: <68D227E48F4B0F4EB6161523402601BE76E89D@PEKW987A.cn001.siemens.net> References: <68D227E48F4B0F4EB6161523402601BE76E89D@PEKW987A.cn001.siemens.net> Message-ID: > Does Live555 support setting maximum connection number? If we >set 5, the 6th connection request will be refused. No; however, you could easily implement this yourself by subclassing "RTSPServer" to include a connection counter, and then managing this by reimplementing the virtual function "createNewClientSession()", and also using a virtual destructor on your subclass. >Can I get active connection detailed information(includes each >client IP address)? Yes, this information is available in the "RTSPClientSession" class (which you can also subclass if you wish - e.g., to add more fields). In particular, the client's IP address is in the "fClientAddr" field. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From samparknisha at rediffmail.com Wed Sep 1 06:18:09 2010 From: samparknisha at rediffmail.com (Nisha Singh) Date: 1 Sep 2010 13:18:09 -0000 Subject: [Live-devel] =?utf-8?q?frame_duration_calculation_in_h263plus?= Message-ID: <20100901131809.15729.qmail@f6mail-145-154.rediffmail.com> Hi, For calculating the duration of a frame in h263, the temporal reference (TR) of the current and next frame has been used. My query is why is it being used for determining the duration of the frame? Is there any way to determine the frame duration or the frame rate of a h263 video? Thanks and Regards, Nisha -------------- next part -------------- An HTML attachment was scrubbed... URL: From sagi at netvision.net.il Wed Sep 1 15:20:02 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Thu, 2 Sep 2010 01:20:02 +0300 Subject: [Live-devel] Getting the FPS at the client side In-Reply-To: References: <007c01cb4864$e0e514b0$a2af3e10$@net.il> Message-ID: <00cf01cb4a23$d2a9b840$77fd28c0$@net.il> Hi Ross, We are writing the server and the client sides with Live555 library. The server broadcasts live source frames (PAL or NTSC) and the client side receives these frames and put them on a small display. We are looking for a way to write the FPS (Or maybe PAL, NTSC) data to the SDP on the server side and using the subsession->videoFPS() function or any other function on the client side get this FPS or (PAL, NTFS metadata). Is it possible? If so what is the best way to implement this. We prefer not to get it from the decoding data. Thanks, Sagi -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, August 31, 2010 7:22 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Getting the FPS at the client side >At the client streamer, when I get a video link (Mpeg4 or H264) I >get a set of parameters but the subsession->videoFPS() (frames per >second) is set to zero. As others have noted, this is not always present in the stream's SDP description. >How can I get the Fps of the video link? In general you will need to decode the video stream - at least, decode it enough so that you can figure out which received data contains the start of video frames. And then, from this - plus the presentation times - you can figure out the frame rate. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Wed Sep 1 17:35:49 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Sep 2010 17:35:49 -0700 Subject: [Live-devel] frame duration calculation in h263plus In-Reply-To: <20100901131809.15729.qmail@f6mail-145-154.rediffmail.com> References: <20100901131809.15729.qmail@f6mail-145-154.rediffmail.com> Message-ID: >For calculating the duration of a frame in h263, the temporal >reference (TR) of the current and next frame has been used. > >My query is why is it being used for determining the duration of the frame? Because it seems to work. >Is there any way to determine the frame duration or the frame rate >of a h263 video? Yes, by comparing the temporal reference of successive frames :-) If you have a better suggestion for how to do this (or, more specifically, a suggestion for how to improve the "H263plusVideoStreamParser" class, then please let us know. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Sep 1 17:53:08 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Sep 2010 17:53:08 -0700 Subject: [Live-devel] Getting the FPS at the client side In-Reply-To: <00cf01cb4a23$d2a9b840$77fd28c0$@net.il> References: <007c01cb4864$e0e514b0$a2af3e10$@net.il> <00cf01cb4a23$d2a9b840$77fd28c0$@net.il> Message-ID: >The server broadcasts live source frames (PAL or NTSC) and the client side >receives these frames and put them on a small display. We are looking for a >way to write the FPS (Or maybe PAL, NTSC) data to the SDP on the server side I suggest subclassing each "RTPSink" class that you use, and redefine the "auxSDPLine()" virtual function to add the following SDP line: a=framerate\r\n where is the frame rate (in frames-per-second). If you do this, then the client will automatically parse this line, and make it available to clients via the "MediaSession:: videoFPS()" function. Of course, this begs the question of how you (the server programmer) gets this frame rate from the input data - but that's for you to figure out. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Sep 2 21:07:18 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 Sep 2010 21:07:18 -0700 Subject: [Live-devel] bug when clock is reset back in time In-Reply-To: <1283160574.6072.23.camel@sebastien-desktop> References: <1283164854.6072.19.camel@sebastien-desktop> <1283160574.6072.23.camel@sebastien-desktop> Message-ID: >No, I still have the 100% CPU usage... Sorry, but I haven't been able to reproduce this - with the latest version of the code. If you're still seeing this, and manage to figure out what part(s) of the code is causing this, please let us know. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sebastien-devel at celeos.eu Fri Sep 3 00:02:42 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 03 Sep 2010 09:02:42 +0200 Subject: [Live-devel] bug when clock is reset back in time In-Reply-To: References: <1283164854.6072.19.camel@sebastien-desktop> <1283160574.6072.23.camel@sebastien-desktop> Message-ID: <1283497362.9128.23.camel@sebastien-desktop> On Thu, 2010-09-02 at 21:07 -0700, Ross Finlayson wrote: > If you're still seeing this, and manage to figure out what part(s) of > the code is causing this, please let us know. I am using gprof to detect what live555 is doing when I reset the clock one hour back in time. I found that the dTimeNow function in RTCP.cpp is called way to often after that (hundreds of time per seconds). I can also give you the number of calls of each function, the call graph of these function, and the gdb backtrace of dTimeNow when it happens : See attached file gprof_output.txt Please let me know if it helps you or not. Regards, Sebastien. -------------- next part -------------- gdb : #0 dTimeNow () at RTCP.cpp:112 #1 0x0805157b in RTCPInstance::schedule (this=0x86f6ef0, nextTime=1283499945.7241356) at RTCP.cpp:871 #2 0x080515ef in Schedule (nextTime=1283499945.7241356, e=0x86f6ef0) at RTCP.cpp:924 #3 0x080532ea in OnExpire (e=0x86f6ef0, members=2, senders=0, rtcp_bw=160, we_sent=0, avg_rtcp_size=0x86f706c, initial=0x86f7074, tc=1283496344.625545, tp=0x86f7078, pmembers=0x86f7088) at rtcp_from_spec.c:223 #4 0x08051534 in RTCPInstance::onExpire1 (this=0x86f6ef0) at RTCP.cpp:899 #5 0x08051558 in RTCPInstance::onExpire (instance=0x86f6ef0) at RTCP.cpp:673 #6 0x0807b86a in AlarmHandler::handleTimeout (this=0x86f5550) at BasicTaskScheduler0.cpp:34 #7 0x0807a3c1 in DelayQueue::handleAlarm (this=0x86eb00c) at DelayQueue.cpp:180 #8 0x080799db in BasicTaskScheduler::SingleStep (this=0x86eb008, maxDelayTime=0) at BasicTaskScheduler.cpp:150 #9 0x0807b00c in BasicTaskScheduler0::doEventLoop (this=0x86eb008, watchVariable=0x0) at BasicTaskScheduler0.cpp:76 #10 0x0804c55d in main (argc=2, argv=0xb778c0b0) at playCommon.cpp:510 Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 17.08 0.77 0.77 7562157 0.00 0.00 BasicTaskScheduler::SingleStep(unsigned int) 15.07 1.44 0.68 7561236 0.00 0.00 RTCPInstance::schedule(double) 7.25 1.76 0.33 67814062 0.00 0.00 Timeval::operator>=(Timeval const&) const 7.25 2.09 0.33 7561236 0.00 0.00 RTCPInstance::onExpire1() 6.25 2.37 0.28 7561240 0.00 0.00 rtcp_interval 4.80 2.58 0.21 15122488 0.00 0.00 dTimeNow() 4.24 2.77 0.19 7561236 0.00 0.00 OnExpire 3.91 2.95 0.17 45377614 0.00 0.00 HandlerIterator::next() 3.68 3.12 0.17 30000480 0.00 0.00 Timeval::operator-=(DelayInterval const&) 3.12 3.25 0.14 7561236 0.00 0.00 BasicTaskScheduler0::scheduleDelayedTask(long long, void (*)(void*), void*) 2.68 3.38 0.12 7561234 0.00 0.00 AlarmHandler::handleTimeout() 2.23 3.48 0.10 1 0.10 1.40 BasicTaskScheduler0::doEventLoop(char*) 2.01 3.56 0.09 7561236 0.00 0.00 DelayQueue::addEntry(DelayQueueEntry*) 1.79 3.65 0.08 15122474 0.00 0.00 TypeOfEvent 1.56 3.71 0.07 7561236 0.00 0.00 AlarmHandler::~AlarmHandler() 1.45 3.78 0.07 7563096 0.00 0.00 DelayQueue::synchronize() 1.45 3.85 0.07 7561236 0.00 0.00 Schedule 1.34 3.90 0.06 15124313 0.00 0.00 DelayQueue::handleAlarm() 1.23 3.96 0.06 7563095 0.00 0.00 operator-(Timeval const&, Timeval const&) 1.12 4.01 0.05 7562171 0.00 0.00 HandlerIterator::HandlerIterator(HandlerSet&) 1.12 4.06 0.05 DelayQueue::timeToNextAlarm() 1.00 4.11 0.04 7565433 0.00 0.00 HandlerIterator::reset() index % time self children called name [1] 68.1 0.05 3.00 DelayQueue::timeToNextAlarm() [1] 0.12 2.83 7561234/7561234 AlarmHandler::handleTimeout() [2] 0.02 0.02 7561234/7561248 DelayQueue::removeEntry(DelayQueueEntry*) [27] 0.00 0.00 930/7563096 DelayQueue::synchronize() [13] 0.00 0.00 1860/67814062 Timeval::operator>=(Timeval const&) const [15] ----------------------------------------------- 0.12 2.83 7561234/7561234 DelayQueue::timeToNextAlarm() [1] [2] 66.0 0.12 2.83 7561234 AlarmHandler::handleTimeout() [2] 0.04 2.68 7561234/7561236 RTCPInstance::onExpire(RTCPInstance*) [3] 0.01 0.10 7561234/7561234 DelayQueueEntry::handleTimeout() [20] ----------------------------------------------- 0.00 0.00 2/7561236 RTCPInstance::RTCPInstance(UsageEnvironment&, Groupsock*, unsigned int, unsigned char const*, RTPSink*, RTPSource const*, unsigned int) [72] 0.04 2.68 7561234/7561236 AlarmHandler::handleTimeout() [2] [3] 60.8 0.04 2.68 7561236 RTCPInstance::onExpire(RTCPInstance*) [3] 0.33 2.36 7561236/7561236 RTCPInstance::onExpire1() [4] ----------------------------------------------- 0.33 2.36 7561236/7561236 RTCPInstance::onExpire(RTCPInstance*) [3] [4] 59.9 0.33 2.36 7561236 RTCPInstance::onExpire1() [4] 0.19 2.02 7561236/7561236 OnExpire [5] 0.11 0.00 7561236/15122488 dTimeNow() [16] 0.04 0.00 7561236/7561250 RTCPInstance::numMembers() const [29] ----------------------------------------------- 0.19 2.02 7561236/7561236 RTCPInstance::onExpire1() [4] [5] 49.4 0.19 2.02 7561236 OnExpire [5] 0.07 1.54 7561236/7561236 Schedule [6] 0.28 0.06 7561240/7561240 rtcp_interval [14] 0.08 0.00 15122472/15122474 TypeOfEvent [23] 0.00 0.00 4/4 SendRTCPReport [144] 0.00 0.00 4/4 SentPacketSize [145] ----------------------------------------------- 0.07 1.54 7561236/7561236 OnExpire [5] [6] 35.8 0.07 1.54 7561236 Schedule [6] 0.68 0.86 7561236/7561236 RTCPInstance::schedule(double) [7] ----------------------------------------------- 0.68 0.86 7561236/7561236 Schedule [6] [7] 34.3 0.68 0.86 7561236 RTCPInstance::schedule(double) [7] 0.14 0.61 7561236/7561236 BasicTaskScheduler0::scheduleDelayedTask(long long, void (*)(void*), void*) [11] 0.11 0.00 7561236/15122488 dTimeNow() [16] From finlayson at live555.com Fri Sep 3 00:01:25 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 3 Sep 2010 00:01:25 -0700 Subject: [Live-devel] bug when clock is reset back in time In-Reply-To: <1283497362.9128.23.camel@sebastien-desktop> References: <1283164854.6072.19.camel@sebastien-desktop> <1283160574.6072.23.camel@sebastien-desktop> <1283497362.9128.23.camel@sebastien-desktop> Message-ID: > > If you're still seeing this, and manage to figure out what part(s) of >> the code is causing this, please let us know. > >I am using gprof to detect what live555 is doing when I reset the clock >one hour back in time. >I found that the dTimeNow function in RTCP.cpp is called way to often >after that (hundreds of time per seconds). OK, I can reproduce this now. (Before, I apparently wasn't setting the clock back far enough to trigger the problem.) This now gives me enough to work from. I'll see what I can do to fix this... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Sep 3 02:37:18 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 3 Sep 2010 02:37:18 -0700 Subject: [Live-devel] bug when clock is reset back in time Message-ID: OK, I've now installed a new version (2010.09.03) of the code that should fix this particular problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sebastien-devel at celeos.eu Fri Sep 3 05:43:18 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 03 Sep 2010 14:43:18 +0200 Subject: [Live-devel] bug when clock is reset back in time In-Reply-To: References: Message-ID: <1283517798.23844.0.camel@sebastien-desktop> On Fri, 2010-09-03 at 02:37 -0700, Ross Finlayson wrote: > OK, I've now installed a new version (2010.09.03) of the code that > should fix this particular problem. Works fine for me, thanks. From a.nemec at atlas.cz Fri Sep 3 06:32:27 2010 From: a.nemec at atlas.cz (=?UTF-8?B?QWxleGFuZHIgTsSbbWVj?=) Date: Fri, 03 Sep 2010 15:32:27 +0200 Subject: [Live-devel] bug when clock is reset back in time In-Reply-To: <1283517798.23844.0.camel@sebastien-desktop> References: <1283517798.23844.0.camel@sebastien-desktop> Message-ID: <1283520747.523880.6151.nullmailer@mail1009.cent> Dear Sebastien (and Ross), which OS were you using to reproduce this problem? I am using an older live555 release and I could not see this problem, my OS is Windows. I turned back the clock by several hours and everything continues working as expected, no?CPU overload and my openRTSP based client?was still delivering samples with no problems. Might this problem be related to a specific platform only? Thanks Alex ______________________________________________________________ > Od: "S?bastien Escudier" > Komu: LIVE555 Streaming Media - development & use > Datum: 03.09.2010 14:46 > P?edm?t: Re: [Live-devel] bug when clock is reset back in time > On Fri, 2010-09-03 at 02:37 -0700, Ross Finlayson wrote: > OK, I've now installed a new version (2010.09.03) of the code that > should fix this particular problem. Works fine for me, thanks. _______________________________________________ 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 sebastien-devel at celeos.eu Fri Sep 3 06:37:09 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 03 Sep 2010 15:37:09 +0200 Subject: [Live-devel] bug when clock is reset back in time In-Reply-To: <1283520747.523880.6151.nullmailer@mail1009.cent> References: <1283517798.23844.0.camel@sebastien-desktop> <1283520747.523880.6151.nullmailer@mail1009.cent> Message-ID: <1283521029.23844.6.camel@sebastien-desktop> On Fri, 2010-09-03 at 15:32 +0200, Alexandr N?mec wrote: > > Dear Sebastien (and Ross), > > still delivering samples with no problems. Might this problem be > related to a specific platform only? I am using linux, so it may not happen in windows. I didn't test. Regards, Sebastien. From mudassar87 at gmail.com Fri Sep 3 06:50:22 2010 From: mudassar87 at gmail.com (Mudassar Ahmed) Date: Fri, 3 Sep 2010 15:50:22 +0200 Subject: [Live-devel] How to mux live video (RTSP Stream ) and live audio data (Floating point) and then further stream the resultant muxed output to network Message-ID: Hi, I want to use live555 library in a C program where I could take live audio data from a floating point array and video stream from an RTSP server. I want to mux these two streams together and then further stream the resultant muxed out put to the network. any help? -- Engr. Mudassar Ahmed Mughal -------------- next part -------------- An HTML attachment was scrubbed... URL: From digitaltoast at gmail.com Sat Sep 4 00:32:43 2010 From: digitaltoast at gmail.com (Jonathan) Date: Sat, 4 Sep 2010 08:32:43 +0100 Subject: [Live-devel] Windows executable crashes on startup Message-ID: Windows 7 64 bit - it opens the command line window with "Live555 Media Server version 0.42 library 2010.03.15" then immediately quits. Every time. Tried different profiles. Tried running as administrator. Here's the crash log Faulting application name: live555MediaServer.exe, version: 0.0.0.0, time stamp: 0x4c51b789 Faulting module name: live555MediaServer.exe, version: 0.0.0.0, time stamp: 0x4c51b789 Exception code: 0xc0000005 Fault offset: 0x0001ef47 Faulting process id: 0x127c Faulting application start time: 0x01cb4c013e911edc Faulting application path: C:\Downloads\live555MediaServer.exe Faulting module path: C:\Downloads\live555MediaServer.exe From finlayson at live555.com Sat Sep 4 02:52:39 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 4 Sep 2010 02:52:39 -0700 Subject: [Live-devel] Windows executable crashes on startup In-Reply-To: References: Message-ID: Thank you for the report. It turned out that a bad version had accidentally been uploaded. This has now been fixed. Please download a new version - from http://www.live555.com/mediaServer/windows/live555MediaServer.exe - and try again. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gmail at digitaltoast.co.uk Sat Sep 4 08:48:02 2010 From: gmail at digitaltoast.co.uk (Jonathan H) Date: Sat, 4 Sep 2010 16:48:02 +0100 Subject: [Live-devel] Windows executable crashes on startup In-Reply-To: References: Message-ID: Thanks. That seems to work OK. But I appear unable to get it to work with any client I can find - some will play it, but there are no transport controls. If I stop the stream on my web radio, it reverts back to the beginning. Not what I was hoping for. This applies to both my pc and linux boxes. On 4 September 2010 10:52, Ross Finlayson wrote: > Thank you for the report. ?It turned out that a bad version had accidentally > been uploaded. ?This has now been fixed. ?Please download a new version - > from http://www.live555.com/mediaServer/windows/live555MediaServer.exe - and > try again. > -- > > 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 Sat Sep 4 12:40:19 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 4 Sep 2010 12:40:19 -0700 Subject: [Live-devel] Windows executable crashes on startup In-Reply-To: References: Message-ID: >Thanks. That seems to work OK. But I appear unable to get it to work >with any client I can find I recommend using VLC as a client. >some will play it, but there are no transport controls. See and . Not all 'transport control' (aka. 'trick play') operations work on all media types. >If I stop the stream on my web radio, it reverts back to the >beginning. Not what I was hoping for. Are you 'stopping' the stream, or 'pausing' it? Pausing the stream should always work, for any media type. If you 'stop' a stream, however, you should not expect to be able to resume a stream from the same point. That's what "PAUSE" is for. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sawan.das at videonetics.com Sun Sep 5 21:22:14 2010 From: sawan.das at videonetics.com (Sawan Das) Date: Mon, 06 Sep 2010 09:52:14 +0530 Subject: [Live-devel] Stream My own mpeg source Message-ID: <1283746934.3173.4.camel@VTPL-Quad2> Hi all, I am new to live555. I want to stream my own mpeg4 encoded stream. Is there any api documentation so i can integrate the live 555 library. I dont get any api so i can put my own src buffer for streaming. Thanks, Sawan -- Activated By Videonetics Sawan Das Software Engineer Videonetics Technology Pvt. Ltd. sawan.das at videonetics.com +919836275503 www.videonetics.com From finlayson at live555.com Sun Sep 5 21:41:52 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 5 Sep 2010 21:41:52 -0700 Subject: [Live-devel] Stream My own mpeg source In-Reply-To: <1283746934.3173.4.camel@VTPL-Quad2> References: <1283746934.3173.4.camel@VTPL-Quad2> Message-ID: > I am new to live555. I want to stream my own mpeg4 encoded stream. Is >there any api documentation so i can integrate the live 555 library. I >dont get any api so i can put my own src buffer for streaming. Please read the FAQ (which you were asked to read when you joined this mailing list!) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From arang1978 at gmail.com Mon Sep 6 02:26:04 2010 From: arang1978 at gmail.com (Aranganathan Sankaradoss) Date: Mon, 6 Sep 2010 18:26:04 +0900 Subject: [Live-devel] segmentation fault (core dumped) Message-ID: hello Sir, I am desperately in need of your help. I am using openRTSP source code. If I call the main function again then I get the following error "Segmentation fault (core dumped)" My aim for calling the main ( ) function again is that after RTSP server reset, openRTSP must keep trying to connect with RTSP server again. In sessionAfterPlaying ( ) function, instead of calling exit ( ) function, I call main ( ) again. To call main ( ), I just copied the main ( ) into a new function named RTSP_main () and I am just calling RTSP_main ( ) in place of exit ( ). *Log file is as follows* [arang at arang testProgs]$ ./openRTSP -d 2 -t rtsp:// 211.214.160.198/liverepeater/camera.stream Opening connection to 211.214.160.198, port 554... ...remote connection opened Sending request: OPTIONS rtsp://211.214.160.198/liverepeater/camera.streamRTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.08.31) Received 202 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK Supported: play.basic, con.persistent Cseq: 2 Server: Wowza Media Server 2.1.2 build24878 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER Sending request: DESCRIBE rtsp://211.214.160.198/liverepeater/camera.streamRTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.08.31) Accept: application/sdp Received 510 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK Content-Base: rtsp://211.214.160.198/liverepeater/camera.stream/ Date: ?, 6 9? 2010 17:20:47 KST Content-Length: 211 Session: 582904228;timeout=60 Expires: ?, 6 9? 2010 17:20:47 KST Cseq: 3 Content-Type: application/sdp Server: Wowza Media Server 2.1.2 build24878 v=0 o=- 582904228 582904228 IN IP4 127.0.0.1 s=WowzaMediaServer c=IN IP4 0.0.0.0 t=0 0 a=sdplang:en a=range:npt=now- a=control:* m=video 0 RTP/AVP 98 a=rtpmap:98 MP2T/90000 a=control:mpegts-transport Opened URL "rtsp://211.214.160.198/liverepeater/camera.stream", returning a SDP description: v=0 o=- 582904228 582904228 IN IP4 127.0.0.1 s=WowzaMediaServer c=IN IP4 0.0.0.0 t=0 0 a=sdplang:en a=range:npt=now- a=control:* m=video 0 RTP/AVP 98 a=rtpmap:98 MP2T/90000 a=control:mpegts-transport Created receiver for "video/MP2T" subsession (client ports 55154-55155) Sending request: SETUP rtsp:// 211.214.160.198/liverepeater/camera.stream/mpegts-transport RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.08.31) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Received 229 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK Date: ?, 6 9? 2010 17:20:47 KST Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Session: 582904228;timeout=60 Expires: ?, 6 9? 2010 17:20:47 KST Cseq: 4 Server: Wowza Media Server 2.1.2 build24878 Setup "video/MP2T" subsession (client ports 55154-55155) Created output file: "video-MP2T-1" Sending request: PLAY rtsp://211.214.160.198/liverepeater/camera.stream/RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.08.31) Session: 582904228 Range: npt=0.000-2.000 Received a complete PLAY response: RTSP/1.0 200 OK Range: npt=now- Session: 582904228;timeout=60 Cseq: 5 Server: Wowza Media Server 2.1.2 build24878 Started playing session Receiving streamed data (for up to 2.000000 seconds)... Sending request: TEARDOWN rtsp://211.214.160.198/liverepeater/camera.stream/RTSP/1.0 CSeq: 6 User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.08.31) Session: 582904228 Opening connection to 211.214.160.198, port 554... ...remote connection opened Sending request: OPTIONS rtsp://211.214.160.198/liverepeater/camera.streamRTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.08.31) Received 202 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK Supported: play.basic, con.persistent Cseq: 2 Server: Wowza Media Server 2.1.2 build24878 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER Sending request: DESCRIBE rtsp://211.214.160.198/liverepeater/camera.streamRTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.08.31) Accept: application/sdp Received 513 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK Content-Base: rtsp://211.214.160.198/liverepeater/camera.stream/ Date: ?, 6 9? 2010 17:20:49 KST Content-Length: 213 Session: 1483665234;timeout=60 Expires: ?, 6 9? 2010 17:20:49 KST Cseq: 3 Content-Type: application/sdp Server: Wowza Media Server 2.1.2 build24878 v=0 o=- 1483665234 1483665234 IN IP4 127.0.0.1 s=WowzaMediaServer c=IN IP4 0.0.0.0 t=0 0 a=sdplang:en a=range:npt=now- a=control:* m=video 0 RTP/AVP 98 a=rtpmap:98 MP2T/90000 a=control:mpegts-transport Opened URL "rtsp://211.214.160.198/liverepeater/camera.stream", returning a SDP description: v=0 o=- 1483665234 1483665234 IN IP4 127.0.0.1 s=WowzaMediaServer c=IN IP4 0.0.0.0 t=0 0 a=sdplang:en a=range:npt=now- a=control:* m=video 0 RTP/AVP 98 a=rtpmap:98 MP2T/90000 a=control:mpegts-transport Created receiver for "video/MP2T" subsession (client ports 39568-39569) Segmentation fault (core dumped) [arang at arang testProgs]$ Regards, Arang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferry at bertin.fr Mon Sep 6 05:00:22 2010 From: ferry at bertin.fr (Guillaume Ferry) Date: Mon, 06 Sep 2010 14:00:22 +0200 Subject: [Live-devel] RTSP video decoding - packets too small Message-ID: <4C84D7D6.6050904@bertin.fr> Hi, I'm using liveMedia library to implement an audio / video RTSP receiver. To do so, I have created a minimal MediumSink subclass, in which I do my decoding stuff (using libav* code). It works really fine with streamed audio, but I can't decode videos properly. I noticed that the frames I'm receiving have really small sizes (sth like 2000 bytes), and should be more around 60000 bytes to contain an 'image'. Maybe I'm wrong here, using a class not dedicated to it... ? Do I have to set a minimal buffer size (for my sink ?). Thanks for your help, Best regards, Guillaume. PS : some interesting insight : when I try to read one of those videos with ffplay (small player contained in ffmpeg sources), it works just fine. -- Guillaume FERRY Bertin Technologies D?partement Bertin Conseil Activit? Traitement de l'Information et du Contenu /T?l/ 01.39.30.62.09 /Fax/ 01.39.30.62.45 /Mail/ ferry at bertin.fr /Web/ www.bertin.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 6 11:40:30 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 6 Sep 2010 11:40:30 -0700 Subject: [Live-devel] RTSP video decoding - packets too small In-Reply-To: <4C84D7D6.6050904@bertin.fr> References: <4C84D7D6.6050904@bertin.fr> Message-ID: >I'm using liveMedia library to implement an audio / video RTSP receiver. >To do so, I have created a minimal MediumSink subclass, in which I >do my decoding stuff (using libav* code). > >It works really fine with streamed audio, but I can't decode videos properly. >I noticed that the frames I'm receiving have really small sizes (sth >like 2000 bytes), and should be more around 60000 bytes to contain >an 'image'. You haven't said anything about what RTP payload format (codec) the video is using. Please post an example of the SDP description returned by the server (in response to the RTSP "DESCRIBE" command). >PS : some interesting insight : when I try to read one of those >videos with ffplay (small player contained in ffmpeg sources), it >works just fine. Have you tried using VLC? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ferry at bertin.fr Mon Sep 6 23:21:04 2010 From: ferry at bertin.fr (Guillaume Ferry) Date: Tue, 07 Sep 2010 08:21:04 +0200 Subject: [Live-devel] RTSP video decoding - packets too small In-Reply-To: References: <4C84D7D6.6050904@bertin.fr> Message-ID: <4C85D9D0.5050706@bertin.fr> Hello Ross, Thanks for your reply. Le 06/09/2010 20:40, Ross Finlayson a ?crit : >> I'm using liveMedia library to implement an audio / video RTSP receiver. >> To do so, I have created a minimal MediumSink subclass, in which I do >> my decoding stuff (using libav* code). >> >> It works really fine with streamed audio, but I can't decode videos >> properly. >> I noticed that the frames I'm receiving have really small sizes (sth >> like 2000 bytes), and should be more around 60000 bytes to contain an >> 'image'. > > You haven't said anything about what RTP payload format (codec) the > video is using. Please post an example of the SDP description > returned by the server (in response to the RTSP "DESCRIBE" command). > Here's the complete SDP : ******************* SDP message ******************** v=0 o=- 1283760697113531 1 IN IP4 127.0.1.1 s=MPEG-1 or 2 Program Stream, streamed by MultimediaRTSPServer i=video:f24.mpg t=0 0 a=tool:LIVE555 Streaming Media v2008.07.24 a=type:broadcast a=control:* a=range:npt=0-105.379 a=x-qt-text-nam:MPEG-1 or 2 Program Stream, streamed by MultimediaRTSPServer a=x-qt-text-inf:video:f24.mpg m=video 0 RTP/AVP 32 c=IN IP4 0.0.0.0 a=control:track1 m=audio 0 RTP/AVP 14 c=IN IP4 0.0.0.0 a=control:track2 ******************* End of SDP ******************** This video has (on purpose) no audio track, so I can focus on video stream only. Payload of value 32 is an MPEG1 or MPEG2 video, if I refer to FFmpeg RTP sources. The thing is, with frames this small (~2000 bytes), I iterate video decoding on it until libavcodec tells me we have a complete frame : it seems to work fine with the first frame (I can't display it though), afterwards, the video decoder seems completely lost. Then, I inserted some traces into FileSink.cpp, and just using openRTSP, I noticed that frames sizes were identical to mine... And i can read the resulting video file perfectly with FFmpeg or VLC. If you have any more ideas, they are of course welcomed, but liveMedia seems not guilty on this one :) Best regards, Guillaume. > >> PS : some interesting insight : when I try to read one of those >> videos with ffplay (small player contained in ffmpeg sources), it >> works just fine. > > Have you tried using VLC? Also fine with VLC... -- Guillaume FERRY Bertin Technologies D?partement Bertin Conseil Activit? Traitement de l'Information et du Contenu /T?l/ 01.39.30.62.09 /Fax/ 01.39.30.62.45 /Mail/ ferry at bertin.fr /Web/ www.bertin.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 6 23:47:03 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 6 Sep 2010 23:47:03 -0700 Subject: [Live-devel] RTSP video decoding - packets too small In-Reply-To: <4C85D9D0.5050706@bertin.fr> References: <4C84D7D6.6050904@bertin.fr> <4C85D9D0.5050706@bertin.fr> Message-ID: >This video has (on purpose) no audio track, so I can focus on video >stream only. >Payload of value 32 is an MPEG1 or MPEG2 video That's correct. An important thing to note about the RTP payload format for MPEG-1 or MPEG-2 video (defined in RFC 2250) is that the data units delivered by RTP are not (necessarily) complete video frames (even though our code refers to them as 'frames' - which is admittedly a bit confusing). For MPEG-1 or 2 video, the data units delivered by RTP - i.e., delivered one-at-a-time by a "MPEG1or2VideoRTPSource" object - can be MPEG headers, or one or more video 'slices', but need not be a complete video frame. (See RFC 2250 section 3.1 and Appendix 1.) This allows a decoder to handle data loss without necessarily discarding an entire video frame, but also means that it has to be a little smarter about properly detecting when it has received enough data to make up an entire frame. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ferry at bertin.fr Mon Sep 6 23:55:55 2010 From: ferry at bertin.fr (Guillaume Ferry) Date: Tue, 07 Sep 2010 08:55:55 +0200 Subject: [Live-devel] RTSP video decoding - packets too small In-Reply-To: References: <4C84D7D6.6050904@bertin.fr> <4C85D9D0.5050706@bertin.fr> Message-ID: <4C85E1FB.7030305@bertin.fr> Le 07/09/2010 08:47, Ross Finlayson a ?crit : >> This video has (on purpose) no audio track, so I can focus on video >> stream only. >> Payload of value 32 is an MPEG1 or MPEG2 video > > That's correct. > > An important thing to note about the RTP payload format for MPEG-1 or > MPEG-2 video (defined in RFC 2250) is that the data units delivered by > RTP are not (necessarily) complete video frames (even though our code > refers to them as 'frames' - which is admittedly a bit confusing). > For MPEG-1 or 2 video, the data units delivered by RTP - i.e., > delivered one-at-a-time by a "MPEG1or2VideoRTPSource" object - can be > MPEG headers, or one or more video 'slices', but need not be a > complete video frame. (See RFC 2250 section 3.1 and Appendix 1.) This > allows a decoder to handle data loss without necessarily discarding an > entire video frame, but also means that it has to be a little smarter > about properly detecting when it has received enough data to make up > an entire frame. Yes, and I have been confused by the frame naming, especially since it worked just fine with audio files ! I'll dive a little deeper into libav* code, I think my solution lies by there :) Thanks for your help Ross. Best regards, Guillaume. PS : by the way, thanks for the asynchronous API, it was really a key feature I missed. -- Guillaume FERRY Bertin Technologies D?partement Bertin Conseil Activit? Traitement de l'Information et du Contenu /T?l/ 01.39.30.62.09 /Fax/ 01.39.30.62.45 /Mail/ ferry at bertin.fr /Web/ www.bertin.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From oshikztrego at hotmail.com Tue Sep 7 08:05:25 2010 From: oshikztrego at hotmail.com (Oshi Keren-Zur) Date: Tue, 7 Sep 2010 18:05:25 +0300 Subject: [Live-devel] Streaming h264 MPEG-2 TS Message-ID: Hi, We are developing a linux based embedded device which functions as a streaming server. The device has a video encoder which produces h264 MPEG-4 Elementary Stream, Audio encoder, and closed caption source. Our project started off with the requirement to stream the Video by RTP. We used liveMedia for this. As the project evolved additional requirements/limitations were added: 1. Offline streaming of previously captured data with trick-play 2. The Streaming client can only play MPEG-2 ts. After some research regarding extending our use of liveMedia to satisfy these requirements, We reached the conclusion that using liveMedia as it is currently implemented will be difficult since 1. Multiplexing of h.264, audio and closed captions to an MPEG-2 ts is not supported 2. Indexing of h264 video for trick play is not supported. Is our conclusion correct? If not, we would appreciate some guidance on how to solve the above problems. Otherwise, is there some other tool/library that can perform this? Thanks, Oshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 7 13:26:58 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 Sep 2010 13:26:58 -0700 Subject: [Live-devel] Streaming h264 MPEG-2 TS In-Reply-To: References: Message-ID: At 6:05 PM +0300 9/7/10, oshikztrego at hotmail.com wrote: >Hi, >We are developing a linux based embedded device which functions as a >streaming server. Do "we" not have our own domain name? :-) (People who use hobbyist email addresses (@hotmail, @gmail, @yahoo, etc.) are taken less seriously on this mailing list.) >The device has a video encoder which produces h264 MPEG-4 Elementary >Stream, Audio encoder, and closed caption source. >Our project started off with the requirement to stream the Video by >RTP. We used liveMedia for this. > >As the project evolved additional requirements/limitations were added: >1. Offline streaming of previously captured data with trick-play >2. The Streaming client can only play MPEG-2 ts. > >After some research regarding extending our use of liveMedia to >satisfy these requirements, >We reached the conclusion that using liveMedia as it is currently >implemented will be difficult since > >1. Multiplexing of h.264, audio and closed captions to an MPEG-2 ts >is not supported We *do* support multiplexing video (including H.264) and audio into a MPEG-2 Transport Stream - using the "MPEG2TransportStreamFromESSource" class. You might also be able to modify this class to support closed captions. >2. Indexing of h264 video for trick play is not supported. That's correct. It's on the 'to do' list, but not currently supported. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jnoring at logitech.com Tue Sep 7 15:07:52 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Tue, 7 Sep 2010 15:07:52 -0700 Subject: [Live-devel] segmentation fault (core dumped) In-Reply-To: References: Message-ID: 2010/9/6 Aranganathan Sankaradoss > hello Sir, > > I am desperately in need of your help. > > > I am using openRTSP source code. If I call the main function again then I > get the following error "Segmentation fault (core dumped)" > Have you analyzed the dump file to get a callstack? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sawan.das at videonetics.com Wed Sep 8 04:06:51 2010 From: sawan.das at videonetics.com (Sawan Das) Date: Wed, 08 Sep 2010 16:36:51 +0530 Subject: [Live-devel] Stream My own mpeg source In-Reply-To: References: <1283746934.3173.4.camel@VTPL-Quad2> Message-ID: <1283944011.8796.1.camel@VTPL-Quad2> Sorry, But I dont get any information regarding specific src streaming or api documentation... On Sun, 2010-09-05 at 21:41 -0700, Ross Finlayson wrote: > > I am new to live555. I want to stream my own mpeg4 encoded stream. Is > >there any api documentation so i can integrate the live 555 library. I > >dont get any api so i can put my own src buffer for streaming. > > Please read the FAQ (which you were asked to read when you joined > this mailing list!) -- Activated By Videonetics Sawan Das Software Engineer Videonetics Technology Pvt. Ltd. sawan.das at videonetics.com +919836275503 www.videonetics.com From finlayson at live555.com Wed Sep 8 06:28:03 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Sep 2010 06:28:03 -0700 Subject: [Live-devel] Stream My own mpeg source In-Reply-To: <1283944011.8796.1.camel@VTPL-Quad2> References: <1283746934.3173.4.camel@VTPL-Quad2> <1283944011.8796.1.camel@VTPL-Quad2> Message-ID: >Sorry, But I dont get any information regarding specific src streaming >or api documentation... Grumble... http://www.live555.com/liveMedia/faq.html#doc Also, because you asked about streaming MPEG-4 video, note the "testMPEG4VideoStreamer" (multicast) and "testOnDemandRTSPServer" (unicast) demo applications, and see http://www.live555.com/liveMedia/faq.html#liveInput and http://www.live555.com/liveMedia/faq.html#liveInput-unicast -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tamj01 at hotmail.com Wed Sep 8 08:00:10 2010 From: tamj01 at hotmail.com (John Tam) Date: Wed, 8 Sep 2010 11:00:10 -0400 Subject: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client In-Reply-To: References: , Message-ID: Hello, Thanks for the fix. And I will take your advise and use a different email account when I post a new issue. For the moment, I am running into another senario of a runaway RTP-over-TCP session, and it is preventing me from testing your last fix. The problem is in the SocketDescriptor::tcpReadHandler1() function between the lines 362-368 in RTPInterface.cpp. What happens is that the handler could not complete to frame the TEARDOWN command before the client shuts the socket. It results in a socket read error, and there is no provision to teardown the client session. For whatever reason, this senario keeps happening to me nowadays although I am using the same client program [VLC 0.9.6] as before, and I cannot verify your last fix. Regards, John Tam > Date: Tue, 31 Aug 2010 11:11:37 -0700 > To: live-devel at ns.live555.com > From: finlayson at live555.com > Subject: Re: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client > > >I am using the RTSP server functionality of the LiveMedia library, > >and I might have resolved a client session management issue. The > >senario is when a ServerMediaSubsession is shared > >[reuseFirstSource=True] and clients choose RTP-over-TCP for > >streaming mode, only the last requested RTP-over-TCP > >RTSPClientSession can be torn down. All of the objects under the > >ServerMediaSession will be runaways. The MediaSink keeps playing, > >and the RTPInstance writes with socket error. The stderr shows > >socket write attempts after all of the RTSP clients are closed. > > > >I am trying to limit the scope of the impacted code, and there seems > >to be two area in the RTPInstance.cpp that are contributing to the > >problem. #1, The > >RTPInterface::setServerRequestAlternativeByteHandler() function is > >overwriting the handler and clientData of an already assigned > >SocketDescriptor object. It makes all existing socket descriptor of > >the server media subsession to map to the latest RTSPClientSession > >instance. #2, When RTCPInstance::addStreamSocket() function adds a > >new stream channel, the RTPInterface::stopNetworkReading() function > >calls deregisterSocket() and wipes out the existing SocketDescriptor > >to RTSPClientSession mapping. Therefore, only the last newly added > >SocketDescriptor has a valid fServerRequestAlternativeByteHandler to > >notify of RTSP TEARDOWN command. > > At first I didn't pay much attention to this email, both because you > were (at first) working with an old version of the code, but also > because you were using a "@hotmail.com" email address, which serious > professionals do not use. (If you want to be taken seriously on this > mailing list, then you should not use "@hotmail", "@yahoo", > "@gmail"-type addresses :-) > > But your analysis of the problem was exactly right. I have now > installed a new version of the code (2010.08.31) that should, I hope, > fix this 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtam at ivcco.com Wed Sep 8 09:22:13 2010 From: jtam at ivcco.com (John Tam) Date: Wed, 8 Sep 2010 11:22:13 -0500 Subject: [Live-devel] Graceful handling of socket error In-Reply-To: <5596F629427ED04B8D07502DE0500E6925787BE394@AUSP01VMBX29.collaborationhost.net> References: <5596F629427ED04B8D07502DE0500E6925787BE394@AUSP01VMBX29.collaborationhost.net> Message-ID: <5596F629427ED04B8D07502DE0500E6925787BE396@AUSP01VMBX29.collaborationhost.net> Hello, I am suggesting the call to abort() in the function BasicTaskScheduler::SingleStep() at line 95 in BasicTaskScheduler.cpp to be replace with something that is less destructive (C++ exception?) since a socket error can happen for legitimate reasons (remote closed, ...). Regards, John Tam -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 8 14:58:50 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Sep 2010 14:58:50 -0700 Subject: [Live-devel] Graceful handling of socket error In-Reply-To: <5596F629427ED04B8D07502DE0500E6925787BE396@AUSP01VMBX29.collaborationhost .net> References: <5596F629427ED04B8D07502DE0500E6925787BE394@AUSP01VMBX29.collaborationhost .net> <5596F629427ED04B8D07502DE0500E6925787BE396@AUSP01VMBX29.collaborationhost .net> Message-ID: >I am suggesting the call to abort() in the function >BasicTaskScheduler::SingleStep() at line 95 in >BasicTaskScheduler.cpp to be replace with something that is less >destructive (C++ exception?) since a socket error can happen for >legitimate reasons (remote closed, ...). Perhaps, although my intention for this call to "abort()" (and others in the code) was that it be a "should never get called" situation. The preceding "if" statement is supposed to catch the small set of error codes that we expect to see in this situation. So, my question is: What specific error code(s) are you seeing in this situation? (Also, are you running Windows, or a Unix system?) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Wed Sep 8 16:12:52 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Wed, 8 Sep 2010 16:12:52 -0700 Subject: [Live-devel] Graceful handling of socket error In-Reply-To: References: Message-ID: On Wed, Sep 8, 2010 at 2:58 PM, Ross Finlayson wrote: > I am suggesting the call to abort() in the function > BasicTaskScheduler::SingleStep() at line 95 in BasicTaskScheduler.cpp to be > replace with something that is less destructive (C++ exception?) since a > socket error can happen for legitimate reasons (remote closed, ...). > > > Perhaps, although my intention for this call to "abort()" (and others in > the code) was that it be a "should never get called" situation. The > preceding "if" statement is supposed to catch the small set of error codes > that we expect to see in this situation. > > So, my question is: What specific error code(s) are you seeing in this > situation? (Also, are you running Windows, or a Unix system?) > IMO, it's generally bad form for a _library_ to call abort() or exit(); it basically means some internal library error is more important than anything that could possibly be going on in the actual application, which is highly unlikely. Our application does a lot more than just stream video; to have our RTSP server library drop the whole process is a pretty thuggish method to communicate failure. These calls should be reserved for application code itself. I think you're better off A) attempting to recover or B) crashing outright or C) returning some error to the application or even D) doing nothing. I would not consider using C++ exceptions, they're an architectural disaster in my not-so-humble opinion (and particularly so with embedded platforms, there are a few "gotchas," see https://developer.mozilla.org/en/C___Portability_Guide for more info). -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 8 16:43:49 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Sep 2010 16:43:49 -0700 Subject: [Live-devel] Graceful handling of socket error In-Reply-To: References: Message-ID: I pretty much agree with this. What I'll probably do (in some future release) is change the calls to "abort()" to some new virtual function (of the "UsageEnvironment" class) called "internalError()" (or something). The default implementation of this might still be to call "abort()", but developers can easily reimplent this in their own "UsageEnvironment" subclass if they wish. And I also agree with you about C++ exceptions. (They do exist in a couple of places in the code (to help implement byte-stream parsing), but I'd like to get rid of them someday.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Sep 8 18:47:49 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Sep 2010 18:47:49 -0700 Subject: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client In-Reply-To: References: , Message-ID: >Thanks for the fix. And I will take your advise and use a different >email account when I post a new issue. For the moment, I am running >into another senario of a runaway RTP-over-TCP session, and it is >preventing me from testing your last fix. > >The problem is in the SocketDescriptor::tcpReadHandler1() >function between the lines 362-368 in RTPInterface.cpp. What >happens is that the handler could not complete to frame the TEARDOWN >command before the client shuts the socket. It results in a socket >read error, and there is no provision to teardown the client session. Thanks for the report. Unfortunately I can't reproduce this myself, so you're going to have to help track this down a little more. It's strange that you're getting a socket read error before the server has read, parsed and processed the incoming "TEARDOWN" request. What is supposed to be happening is that "RTSPServer:: handleRequestBytes(1)" gets called - one byte at a time - for each byte in the incoming "TEARDOWN" request. When it sees the last byte of the request (the final LF in the CR-LF-CR-LF sequence), it should then be calling "handleCmd_withinSession("TEARDOWN", ...)", which should then in turn call "handleCmd_TEARDOWN()" to close the session. It is only the *next* (single-byte) socket read that should be getting a read error. Could you look into why this is not working properly for you? > For whatever reason, this senario keeps happening to me nowadays >although I am using the same client program [VLC 0.9.6] as before, >and I cannot verify your last fix. Does the problem still occur if you use a new version of VLC (1.1.3)? It shouldn't make a difference, but it's worth checking... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtam at ivcco.com Wed Sep 8 21:02:37 2010 From: jtam at ivcco.com (John Tam) Date: Wed, 8 Sep 2010 23:02:37 -0500 Subject: [Live-devel] Graceful handling of socket error In-Reply-To: References: , Message-ID: <5596F629427ED04B8D07502DE0500E6925787BE397@AUSP01VMBX29.collaborationhost.net> Ross, To answer your earlier question, I get error code 10038 on Windows, and I suppose 10054 is very possible. I agree a hook like a virtual function in the UsageEnvironment is a good solution. And I want to add to the requirement that it could have some mechanism to communicate where the source [code] of failure since it might also be replacing other abort() calls in the liveMedia library. As for handling the socket error in question, there will be much work to identify the type of [client or server] session and perform the appropriate cleanup. Regards, John Tam ________________________________________ ???: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] ?? Ross Finlayson [finlayson at live555.com] ????: Wednesday, 8 September, 2010 19:43 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] Graceful handling of socket error I pretty much agree with this. What I'll probably do (in some future release) is change the calls to "abort()" to some new virtual function (of the "UsageEnvironment" class) called "internalError()" (or something). The default implementation of this might still be to call "abort()", but developers can easily reimplent this in their own "UsageEnvironment" subclass if they wish. And I also agree with you about C++ exceptions. (They do exist in a couple of places in the code (to help implement byte-stream parsing), but I'd like to get rid of them someday.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Sep 9 00:33:06 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Sep 2010 00:33:06 -0700 Subject: [Live-devel] Graceful handling of socket error In-Reply-To: <5596F629427ED04B8D07502DE0500E6925787BE397@AUSP01VMBX29.collaborationhost .net> References: , <5596F629427ED04B8D07502DE0500E6925787BE397@AUSP01VMBX29.collaborationhost .net> Message-ID: >To answer your earlier question, I get error code 10038 on Windows This is "ENOTSOCK", which indicates that one of the sockets specified in the "select()" call was not actually a socket - either because it had not actually been created, or because it had already been closed. This indicates a bug somewhere, because our code is supposed to be calling "turnOnBackgroundReadHandling()" only on actual sockets, and calling "turnOffBackgroundReadHandling()" on every socket before it gets closed. It would be nice to figure out this bug... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From arang1978 at gmail.com Wed Sep 8 19:08:42 2010 From: arang1978 at gmail.com (Aranganathan Sankaradoss) Date: Thu, 9 Sep 2010 11:08:42 +0900 Subject: [Live-devel] segmentation fault (core dumped) (Jeremy Noring) Message-ID: >>Date: Tue, 7 Sep 2010 15:07:52 -0700 >>From: Jeremy Noring >>Subject: Re: [Live-devel] segmentation fault (core dumped) >>To: "LIVE555 Streaming Media - development & use" < live-devel at ns.live555.com> >>Message-ID: >> >>Content-Type: text/plain; charset="iso-8859-1" >>2010/9/6 Aranganathan Sankaradoss >> hello Sir, >> >> I am desperately in need of your help. >> >> >> I am using openRTSP source code. If I call the main function again then I >> get the following error "Segmentation fault (core dumped)" >> >Have you analyzed the dump file to get a callstack? Hello sir, I got the call stack using backtrace command in gdb. Please go through the call stack #0 RTSPClient::sessionURL (this=) at include/MediaSession.hh:52 #1 0x08052a93 in RTSPClient::constructSubsessionURL (this=) at RTSPClient.cpp:1193 #2 0x0805438a in RTSPClient::sendRequest (this=) at RTSPClient.cpp:581 #3 0x08056dab in RTSPClient::sendSetupCommand (this=) at RTSPClient.cpp:63 #4 0x08049392 in setupSubsession (subsession=) at openRTSP.cpp:38 #5 0x0804a773 in setupStreams () at playCommon.cpp:1124 #6 0x0804b517 in continueAfterDESCRIBE (resultCode=) at playCommon.cpp:1095 #7 0x08055d6f in RTSPClient::handleResponseBytes (this=) at RTSPClient.cpp:1570 #8 0x08055f32 in RTSPClient::incomingDataHandler1 (this=) at RTSPClient.cpp:1325 #9 0x08055f49 in RTSPClient::incomingDataHandler (instance=) at RTSPClient.cpp:1318 #10 0x08071721 in BasicTaskScheduler::SingleStep (this=) at BasicTaskScheduler.cpp:160 #11 0x08072877 in BasicTaskScheduler0::doEventLoop (this=) at BasicTaskScheduler0.cpp:76 #12 0x0804c2e0 in RTSP_main () at playCommon.cpp:545 #13 0x0804ce0a in main (argc=, argv=0xbfc9aa50) at playCommon.cpp:972 in MediaSession.hh the the following statments get executed, I get the "segmentation fault(core dumped)" error. char const* controlPath() const { return fControlPath; } For a purpose, I need to call the main () again after it exits, so in main ( ) after env->taskScheduler().doEventLoop(&watchVariable); I call RTSP_main(). It is just another copy of actual main ( ) . Sir, your ideas will be helpful for me. Regards, Arang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Thu Sep 9 02:59:47 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Thu, 09 Sep 2010 11:59:47 +0200 Subject: [Live-devel] [vlc-devel] A Bug: VLC CANNOT seek RTSP stream , and its solution In-Reply-To: <14abceb.18ea.12af5dbe7da.Coremail.shaofa@vip.163.com> References: <14abceb.18ea.12af5dbe7da.Coremail.shaofa@vip.163.com> Message-ID: <1284026387.7212.59.camel@sebastien-desktop> Hi, Thanks for the report. You point out some modification in live555 so I copy this email to live555 mailing list. Best regards. On Thu, 2010-09-09 at 17:38 +0800, sf wrote: > Hi, All > I think I have found a bug with live555 library which is used > in VLC media player. When it' playing a RTSP stream from the > MediaServer, I drag the slider to a new position but an error > occurs : The slider will no longer move, while the video and audio > still run correctly. (the tsx file is right there, and sequential > playing is no problem). So I say, the live555 library with the client > is not able to 'SEEK' to a position. > > The cause is located in the live555 library. See > MediaSession.cpp, MediaSubsession::getNormalPlayTime() . Look at > this line: > u_int32_t timestampOffset = > rtpSource()->curPacketRTPTimestamp() - rtpInfo.timestamp; > In the suitation of 'SEEKING', it will not work because > rtpInfo.timestamp will be larger than curPacketRTPTimestamp. According > to RFC 2326, the media server echo a reply in response of 'PLAY' with > the timestamp and seq_num. And should it be noted that the seq_num can > be something in the future. So current RTP packet's timestamp maybe > smaller than the rtpInfo.timestamp. > > A solution to this problem can be just add a judgement before > compute the new fNPT_PTS_Offset: > .......................... > if (rtpInfo.infoIsNew) { > if(rtpSource()->curPacketRTPSeqNum() < rtpInfo.seqNum) return > -0.1; // add this line > u_int32_t timestampOffset = rtpSource()->curPacketRTPTimestamp() > - rtpInfo.timestamp; > double nptOffset = > (timestampOffset/(double)(rtpSource()->timestampFrequency()))*scale(); > .......................... > > Then the VLC media player will work fine. > > John. ShaoFa > 2010-9-9 > > > > _______________________________________________ > vlc-devel mailing list > To unsubscribe or modify your subscription options: > http://mailman.videolan.org/listinfo/vlc-devel From wlm at tid.es Thu Sep 9 02:21:27 2010 From: wlm at tid.es (wlm) Date: Thu, 09 Sep 2010 11:21:27 +0200 Subject: [Live-devel] How can I to delete the part of dates Message-ID: <4C88A717.9070008@tid.es> Hello Friends, How Can I to delete the part of datos in the session RTSP, I want only to use the establishment the session between the client and server Where is that part the code that can i to delete? Thanks so much Regards William From shaofa at vip.163.com Thu Sep 9 02:27:04 2010 From: shaofa at vip.163.com (sf) Date: Thu, 9 Sep 2010 17:27:04 +0800 (CST) Subject: [Live-devel] A Bug with "MediaSubsession::getNormalPlayTime()" and its solution Message-ID: <18093db.17c2.12af5d1d7be.Coremail.shaofa@vip.163.com> Hi, All I think I have found a bug with live555 library which is used in VLC media player. When it' playing a RTSP stream from the MediaServer, I drag the slider to a new position but an error occurs : The slider will no longer move, while the video and audio still run correctly. (the tsx file is right there, and sequential playing is no problem). So I say, the live555 library with the client is not able to 'SEEK' to a position. The cause is located in MediaSubsession::getNormalPlayTime() , MediaSession.cpp. Look at this line: u_int32_t timestampOffset = rtpSource()->curPacketRTPTimestamp() - rtpInfo.timestamp; In the suitation of 'SEEKING', it will not work because rtpInfo.timestamp will be larger than curPacketRTPTimestamp. According to RFC 2326, the media server echo a reply in response of 'PLAY' with the timestamp and seq_num. And should it be noted that the seq_num can be something in the future. So current RTP packet's timestamp maybe smaller than the rtpInfo.timestamp. A solution to this problem can be just add a judgement before compute the new fNPT_PTS_Offset: .......................... if (rtpInfo.infoIsNew) { if(rtpSource()->curPacketRTPSeqNum() < rtpInfo.seqNum) return -0.1; // add this line u_int32_t timestampOffset = rtpSource()->curPacketRTPTimestamp() - rtpInfo.timestamp; double nptOffset = (timestampOffset/(double)(rtpSource()->timestampFrequency()))*scale(); .......................... Then the VLC media will work fine. John. ShaoFa 2010-9-9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 9 06:55:38 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Sep 2010 06:55:38 -0700 Subject: [Live-devel] A Bug with "MediaSubsession::getNormalPlayTime()" and its solution In-Reply-To: <18093db.17c2.12af5d1d7be.Coremail.shaofa@vip.163.com> References: <18093db.17c2.12af5d1d7be.Coremail.shaofa@vip.163.com> Message-ID: > I think I have found a bug with live555 library which is >used in VLC media player. When it' playing a RTSP stream from the >MediaServer, I drag the slider to a new position but an error >occurs : The slider will no longer move, while the video and audio >still run correctly. (the tsx file is right there, and sequential >playing is no problem). So I say, the live555 library with the >client is not able to 'SEEK' to a position. > > The cause is located in MediaSubsession::getNormalPlayTime() >, MediaSession.cpp. Look at this line: > u_int32_t timestampOffset = >rtpSource()->curPacketRTPTimestamp() - rtpInfo.timestamp; >In the suitation of 'SEEKING', it will not work because >rtpInfo.timestamp will be larger than curPacketRTPTimestamp. That should not be happening. The client (VLC) does a 'seek' operation by doing a RTSP "PLAY" command. The response to this "PLAY" command will contain a "RTP-Info:" header, which our library will automatically interpret by setting the "MediaSubsession::rtpInfo" structure (and setting the "rtpInfo.infoIsNew" flag). Any subsequent RTP packets sent by the server - and received by the client - will have occurred *after* the 'seek' operation, and so their timestamps should be at least as large as the value in "rtpInfo.timestamp". So, I don't understand why you are seeing a situation where - for a packet that you receive just after a 'seek' operation - "curPacketRTPTimestamp" is smaller than "rtpInfo.timestamp" (unless the timestamp field has just wrapped around, which we will handle OK). Are you using an up-to-date version of the "LIVE555 Media Server"? I have tested playing an indexed Transport Stream file using "Live555 Media Server" version 0.5, and VLC version 1.1.3, and do not see any problem; I am able to seek either forwards or backwards, with no problem. > A solution to this problem can be just add a judgement before >compute the new fNPT_PTS_Offset: > .......................... > if (rtpInfo.infoIsNew) { > if(rtpSource()->curPacketRTPSeqNum() < rtpInfo.seqNum) return >-0.1; // add this line First, when comparing RTP sequence numbers, you should use the function "seqNumLT()" instead of "<", to allow for the possibility of the sequence number wrapping around. So the new line should be: if(seqNumLT(rtpSource()->curPacketRTPSeqNum(), rtpInfo.seqNum)) return -0.1; But again, I don't see how this can be happening. For the packet that you receive just after a 'seek' operation, the RTP sequence number should be at least as large as "rtpInfo.seqNum" (modulo wraparound) - not smaller. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ewpaus at pobox.com Thu Sep 9 08:45:34 2010 From: ewpaus at pobox.com (Estelle W. Paus) Date: Thu, 09 Sep 2010 11:45:34 -0400 Subject: [Live-devel] more RTSP/H264 questions Was:Using openRTSP to receive and decode h264 Message-ID: <4C89011E.9020508@pobox.com> Hi, First I would like to thank all of you that have given me advice. I appreciate it very much. It is so nice to get responses. This is a very nice community of developers. I hope that one day, I can be a helpful person too. I have a follow up question regarding several of your responses. I was told to understand the difference between source and sink. I was told that a source is used for streaming (out), while a sink is for receiving. I read the FAQ. I have been stepping through mplayer with gdb to try to find out where I insert the NAL startcode and how. Now when I use tab-completion to create my break point in gdb, it will not allow me to add H264VideoRTPSink. It will only allow me to add H264VideoRTPSource. I am using VLC to stream an H264 video via RTP using an sdp file. Mplayer is receiving this video that is to say, the role of the mplayer in this scenerio is the "sink". And mplayer seems to be working fine. The video is displayed like I expect. Why am I not finding H264VideoRTPSink when I step through this running code? I have tried stepping through openRTSP. But, I can't find what I need. Perhaps, it is in playCommon. But, I haven't figured out how to debug playCommon since it requires input from openRTSP. If anyone has any help for that, I'd appreciate that too. Thank you, Estelle From finlayson at live555.com Thu Sep 9 12:16:21 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Sep 2010 12:16:21 -0700 Subject: [Live-devel] more RTSP/H264 questions Was:Using openRTSP to receive and decode h264 In-Reply-To: <4C89011E.9020508@pobox.com> References: <4C89011E.9020508@pobox.com> Message-ID: >I was told to understand the difference between source and sink. I >was told that a source is used for streaming (out), while a sink is >for receiving. No. Read this FAQ entry http://www.live555.com/liveMedia/faq.html#control-flow again (especially the last paragraph). I have updated it to try to make the explanation clearer. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tamj01 at hotmail.com Thu Sep 9 12:16:37 2010 From: tamj01 at hotmail.com (John Tam) Date: Thu, 9 Sep 2010 15:16:37 -0400 Subject: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client In-Reply-To: References: , , , , Message-ID: Strange indeed. This unable to frame the TEARDOWN message has not been happening before, otherwise, I would not be able to track down the original reported problem. I guess having to read one byte at a time, going back to the outer loop and doing a select() can open a big window of opportunity for things to happen. I ran it again with VLC 1.1.3. I am attaching the console debug messages and Wireshark network capture. In this instance, the tcpReadHandler1() code began to read the 'T' then turned off reading of socket and left the TCP session dangling. The network capture shows the whole TEARDOWN message being sent by the client, and the client even sent a RTCP BYE before closing the connection. I think in general, the tcpReadHandler1() should initiate some cleanup upon a TCP socket failure because it knows the association between the socket number and the client session object. I just cannot come up iwth a good suggestion to tie it together to the fServerRequestAlternativeByteHandler callback. [repeat .....] sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: completed sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: completed sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: completed sendRTPOverTCP: 762 bytes over channel 0 (socket 4172) sendRTPOverTCP: completed sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: completed RTSPClientSession[03A1D018]::handleRequestBytes() read 1 new bytes:T sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: failed! sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: failed! sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: failed! sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: failed! sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172) sendRTPOverTCP: failed! [repeat .....] Regards, John Tam Date: Wed, 8 Sep 2010 18:47:49 -0700 To: live-devel at ns.live555.com From: finlayson at live555.com Subject: Re: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client Thanks for the fix. And I will take your advise and use a different email account when I post a new issue. For the moment, I am running into another senario of a runaway RTP-over-TCP session, and it is preventing me from testing your last fix. The problem is in the SocketDescriptor::tcpReadHandler1() function between the lines 362-368 in RTPInterface.cpp. What happens is that the handler could not complete to frame the TEARDOWN command before the client shuts the socket. It results in a socket read error, and there is no provision to teardown the client session. Thanks for the report. Unfortunately I can't reproduce this myself, so you're going to have to help track this down a little more. It's strange that you're getting a socket read error before the server has read, parsed and processed the incoming "TEARDOWN" request. What is supposed to be happening is that "RTSPServer:: handleRequestBytes(1)" gets called - one byte at a time - for each byte in the incoming "TEARDOWN" request. When it sees the last byte of the request (the final LF in the CR-LF-CR-LF sequence), it should then be calling "handleCmd_withinSession("TEARDOWN", ...)", which should then in turn call "handleCmd_TEARDOWN()" to close the session. It is only the *next* (single-byte) socket read that should be getting a read error. Could you look into why this is not working properly for you? For whatever reason, this senario keeps happening to me nowadays although I am using the same client program [VLC 0.9.6] as before, and I cannot verify your last fix. Does the problem still occur if you use a new version of VLC (1.1.3)? It shouldn't make a difference, but it's worth checking...-- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ConsoleMessages.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: NetworkCapture.ethereal URL: From tamj01 at hotmail.com Thu Sep 9 12:24:20 2010 From: tamj01 at hotmail.com (John Tam) Date: Thu, 9 Sep 2010 15:24:20 -0400 Subject: [Live-devel] more RTSP/H264 questions Was:Using openRTSP to receive and decode h264 In-Reply-To: <4C89011E.9020508@pobox.com> References: <4C89011E.9020508@pobox.com> Message-ID: Let's say in your case, MPlayer is the client program and VLC is the server program. The source & sink here mean the objects within a program. For your instance of the MPlayer program, the source is H264VideoRTPSource and the sink is some kind of renderer. You will find H264VideoRTPSink in your VLC. > Date: Thu, 9 Sep 2010 11:45:34 -0400 > From: ewpaus at pobox.com > To: live-devel at ns.live555.com > Subject: [Live-devel] more RTSP/H264 questions Was:Using openRTSP to receive and decode h264 > > Hi, > First I would like to thank all of you that have given me advice. I > appreciate it very much. It is so nice to get responses. This is a > very nice community of developers. I hope that one day, I can be a > helpful person too. > > I have a follow up question regarding several of your responses. > > I was told to understand the difference between source and sink. I was > told that a source is used for streaming (out), while a sink is for > receiving. I read the FAQ. > > I have been stepping through mplayer with gdb to try to find out where I > insert the NAL startcode and how. > > Now when I use tab-completion to create my break point in gdb, it will > not allow me to add H264VideoRTPSink. It will only allow me to add > H264VideoRTPSource. > > I am using VLC to stream an H264 video via RTP using an sdp file. > Mplayer is receiving this video that is to say, the role of the mplayer > in this scenerio is the "sink". And mplayer seems to be working fine. > The video is displayed like I expect. > > Why am I not finding H264VideoRTPSink when I step through this running code? > > I have tried stepping through openRTSP. But, I can't find what I need. > Perhaps, it is in playCommon. But, I haven't figured out how to debug > playCommon since it requires input from openRTSP. If anyone has any > help for that, I'd appreciate that too. > > Thank you, > Estelle > > > _______________________________________________ > 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 shaofa at vip.163.com Thu Sep 9 18:37:38 2010 From: shaofa at vip.163.com (sf) Date: Fri, 10 Sep 2010 09:37:38 +0800 (CST) Subject: [Live-devel] A Bug with "MediaSubsession::getNormalPlayTime()" and its solution (John.Shaofa) Message-ID: <937389.4afe.12af94a6dea.Coremail.shaofa@vip.163.com> >That should not be happening. The client (VLC) does a 'seek' >operation by doing a RTSP "PLAY" command. The response to this >"PLAY" command will contain a "RTP-Info:" header, which our library >will automatically interpret by setting the >"MediaSubsession::rtpInfo" structure (and setting the >"rtpInfo.infoIsNew" flag). Any subsequent RTP packets sent by the >server - and received by the client - will have occurred *after* the >'seek' operation, and so their timestamps should be at least as large >as the value in "rtpInfo.timestamp". >So, I don't understand why you are seeing a situation where - for a >packet that you receive just after a 'seek' operation - >"curPacketRTPTimestamp" is smaller than "rtpInfo.timestamp" (unless >the timestamp field has just wrapped around, which we will handle >OK). Are you using an up-to-date version of the "LIVE555 Media >Server"? I have tested playing an indexed Transport Stream file >using "Live555 Media Server" version 0.5, and VLC version 1.1.3, and >do not see any problem; I am able to seek either forwards or >backwards, with no problem. >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ Yes, I used latest version of VLC 1.1.3 and media server 0.5, and It produces the same result. Only to add that, If you run the VLC and media server in a same PC machine, you have to 10% chance to reproduce the bug; If you run them it two separate PC computers, you have almost 100% chance to reproduce the problem. John.ShaoFa -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 10 00:25:59 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Sep 2010 00:25:59 -0700 Subject: [Live-devel] A Bug with "MediaSubsession::getNormalPlayTime()" and its solution (John.Shaofa) In-Reply-To: <937389.4afe.12af94a6dea.Coremail.shaofa@vip.163.com> References: <937389.4afe.12af94a6dea.Coremail.shaofa@vip.163.com> Message-ID: >If you run them it two separate PC computers, you have almost 100% >chance to reproduce the problem. No sorry - I'm still not seeing this happen at all. And I still don't see how this situation (an old packet being sent by the server after having responded to a RTSP "PLAY" command (for 'seeking')) can be happening with our (unmodified) RTSP server implementation. However, because it's conceivable that other server implementations might have this problem, I went ahead and added your 'sanity check' to the code, and released a new version: 2010.09.10 -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ternyk at gmail.com Fri Sep 10 03:18:10 2010 From: ternyk at gmail.com (ternyk) Date: Fri, 10 Sep 2010 12:18:10 +0200 Subject: [Live-devel] Writing Speex encoder Filter Message-ID: Hello, I'm trying to implement streaming Speex encoded audio data (RTP Speex payload) from a microphone. I've read FAQ and checked mailing list so I had point of start but now I can not go further. I've decided to start first with streaming WAV file transcoded to Speex. I created SpeexAudioFileServerMediaSubsession which was based on WAVAudioFileServerMediaSubsession but when playing the stream VLC I get only messages (with no audio): .... live555 debug: tk->rtpSource->hasBeenSynchronizedUsingRTCP() main error: ES_OUT_RESET_PCR called main debug: Buffering 0% main debug: Buffering 17% main debug: Buffering 34% main debug: Buffering 51% main debug: Buffering 68% main debug: Buffering 85% main debug: Stream buffering done (1238 ms in 1238 ms) main debug: Decoder buffering done in 0 ms main debug: End of audio preroll main warning: PTS is out of range (15713989), dropping buffer main warning: PTS is out of range (15900246), dropping buffer main warning: PTS is out of range (16089345), dropping buffer main warning: PTS is out of range (16271773), dropping buffer main warning: PTS is out of range (16458644), dropping buffer main warning: PTS is out of range (16646190), dropping buffer main warning: PTS is out of range (16832643), dropping buffer main warning: PTS is out of range (17018080), dropping buffer I wonder if I have to change fPresentationTime? Original time comes from WAVAudioFileSource but after encoding frames with Speex should I do any changes to it? BTW Is there any reliable player for RTP/Speex? Maybe my problem is a player that doesn't support the protocol and codec (I tested with VLC and mplayer) Thanks in advance for help. regards, ternyk Some snippets from my code: ********************************************************* WAVAudioFileServerMediaSubsession: -------------- createNewStreamSource: WAVAudioFileSource* wavSource = WAVAudioFileSource::createNew(envir(), fFileName); ... //add if needed resultSource = uLawFromPCMAudioSource::createNew(envir(), wavSource); resultSource = EndianSwap16::createNew(envir(), wavSource); ... fSamplingFrequency = 8000; fNumChannels = 1; unsigned bitsPerSecond = fSamplingFrequency*fBitsPerSample*fNumChannels; SpeexTranscoder* speexFilter = SpeexTranscoder::createNew(envir(), SPEEX_MODE_NARROWBAND, bitsPerSecond, resultSource); resultSource = speexFilter; return resultSource; ---------------- createNewRTPSink: return SimpleRTPSink::createNew(envir(), rtpGroupsock, 96, fSamplingFrequency, "audio", "speex", fNumChannels); ***************************************************************** in SpeexTranscoder: ----------- SpeexInit: encoder_state = speex_encoder_init( speex_mode ); int tmp; tmp=0; speex_encoder_ctl(encoder_state, SPEEX_SET_VBR, &tmp); int quality = 8; speex_encoder_ctl(encoder_state, SPEEX_SET_QUALITY, &quality); // 8: 27,800[bps] tmp=3; speex_encoder_ctl(encoder_state, SPEEX_SET_COMPLEXITY, &tmp); speex_encoder_ctl( encoder_state, SPEEX_GET_FRAME_SIZE, &speex_frame_size ); speex_bits_init( &encoder_bits ); resampler = speex_resampler_init(1, 44100, 8000, quality, &tmp); --------------- afterGettingFrame1: fFrameSize = TranscodeSpeex(fOrigADU, numBytesRead, fOutBitrate, fTo, fMaxSize, fAvailableBytesForBackpointer); if (fFrameSize == 0) { // internal error - bad ADU data? handleClosure(this); return; } // Complete delivery to the client: fNumTruncatedBytes = numTruncatedBytes; fPresentationTime = presentationTime; fDurationInMicroseconds = durationInMicroseconds; afterGetting(this); ----------- TranscodeSpeex: unsigned SpeexTranscoder::TranscodeSpeex(unsigned char const* fromPtr, unsigned fromSize, unsigned toBitrate, unsigned char* toPtr, unsigned toMaxSize, unsigned& availableBytesForBackpointer) { int err; char tmp[MAX_MP3_FRAME_SIZE]; const spx_int16_t *in = (spx_int16_t*)fromPtr; unsigned in_len = fromSize; spx_int16_t* out = (spx_int16_t*)tmp; unsigned out_len; err = speex_resampler_process_int(resampler, 0, in, &in_len, out, &out_len); speex_bits_reset( &encoder_bits ); speex_encode_int( encoder_state, out, &encoder_bits ); speex_packet_size = speex_bits_write( &encoder_bits, (char*)fTo, toMaxSize); return speex_packet_size; -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 10 07:22:12 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Sep 2010 07:22:12 -0700 Subject: [Live-devel] Writing Speex encoder Filter In-Reply-To: References: Message-ID: >BTW Is there any reliable player for RTP/Speex? Maybe my problem is >a player that doesn't support the protocol and codec (I tested with >VLC and mplayer) I'm not sure about this. You will need to ask about this on a VLC and a MPlayer mailing list. >I'm trying to implement streaming Speex encoded audio data (RTP >Speex payload) from a microphone. I've read FAQ and checked mailing >list so I had point of start but now I can not go further. >I've decided to start first with streaming WAV file transcoded to Speex. >I created SpeexAudioFileServerMediaSubsession which was based on >WAVAudioFileServerMediaSubsession but when playing the stream VLC I >get only messages (with no audio): >.... >live555 debug: tk->rtpSource->hasBeenSynchronizedUsingRTCP() >main error: ES_OUT_RESET_PCR called >main debug: Buffering 0% >main debug: Buffering 17% >main debug: Buffering 34% >main debug: Buffering 51% >main debug: Buffering 68% >main debug: Buffering 85% >main debug: Stream buffering done (1238 ms in 1238 ms) >main debug: Decoder buffering done in 0 ms >main debug: End of audio preroll >main warning: PTS is out of range (15713989), dropping buffer >main warning: PTS is out of range (15900246), dropping buffer >main warning: PTS is out of range (16089345), dropping buffer >main warning: PTS is out of range (16271773), dropping buffer >main warning: PTS is out of range (16458644), dropping buffer >main warning: PTS is out of range (16646190), dropping buffer >main warning: PTS is out of range (16832643), dropping buffer >main warning: PTS is out of range (17018080), dropping buffer > >I wonder if I have to change fPresentationTime? Original time comes >from WAVAudioFileSource but after encoding frames with Speex should >I do any changes to it? From what I can tell, the "fPresentationTime" values from "WAVAudioFileSource" are being passed correctly through your new "SpeexTranscoder" class (which I presume is a "FramedFilter"). One way you can check this, though, is by instrumenting the "MultiFramedRTPSink::afterGettingFrame1()" function ("liveMedia/MultiFramedRTPSink.cpp", line 233) to check whether the parameter values (frameSize, numTruncatedBytes, presentationTime, durationInMicroseconds) look reasonable. If this looks OK, then your next step should be to work with the VLC (and/or MPlayer) developers to figure out why they are not playing the incoming Speex audio stream properly. (They use our library for RTP input, and we handle incoming Speex/RTP streams, but I don't know whether they are decoding/playing it OK.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jnoring at logitech.com Sun Sep 12 12:13:39 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Sun, 12 Sep 2010 12:13:39 -0700 Subject: [Live-devel] segmentation fault (core dumped) In-Reply-To: References: Message-ID: 2010/9/6 Aranganathan Sankaradoss > hello Sir, > > I am desperately in need of your help. > > > I am using openRTSP source code. If I call the main function again then I > get the following error "Segmentation fault (core dumped)" > > My aim for calling the main ( ) function again is that after RTSP server > reset, openRTSP must keep trying to connect with RTSP server again. > > In sessionAfterPlaying ( ) function, instead of calling exit ( ) function, > I call main ( ) again. > To call main ( ), I just copied the main ( ) into a new function named > RTSP_main () and I am just calling RTSP_main ( ) in place of exit ( ). > > Could you post your code? And why are you doing this? It seems like you could have an issue with infinite recursion, for one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinhua.li at siemens.com Sun Sep 12 22:39:34 2010 From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S) Date: Mon, 13 Sep 2010 13:39:34 +0800 Subject: [Live-devel] Close specified client by IP Message-ID: <68D227E48F4B0F4EB6161523402601BE7C07AE@PEKW987A.cn001.siemens.net> Dear all, I have written a control panel to control Live555 VOD server, in this panel, administrator could see active connection's IP addresses, I want to close some specified connections by IP address, now the RTSPServer can receive these specified IP addresses, but how could I close these connections in RTSPServer.cpp? Best regards. -------------------------------------------------------------- ??? Li Yinhua SIEMENS Siemens Ltd., China Nanjing Branch Corporate Technology Development Center (CT DC), Nanjing ?????????????37??????????211100? Tel.: +86 (25) 51171864 Fax: +86 (25) 51171761 Mobile: +86 15895967085 www.siemens.com P Save a tree. Don't print this e-mail unless it's really necessary. IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person. In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????Tell us???????www.siemens.com.cn/compliancehelpdesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferry at bertin.fr Mon Sep 13 07:26:33 2010 From: ferry at bertin.fr (Guillaume Ferry) Date: Mon, 13 Sep 2010 16:26:33 +0200 Subject: [Live-devel] RTSP video decoding - packets too small In-Reply-To: References: <4C84D7D6.6050904@bertin.fr> <4C85D9D0.5050706@bertin.fr> Message-ID: <4C8E3499.7080908@bertin.fr> Hi Ross, I just wanted to keep you in touch about my issue, and I'm glad to say it's now solved. In fact, ffmpeg libraries already contain some useful parsers, and I especially use the 'av_parser_parse' method, which simply reads an input buffer and rebuilds a proper output frame. Once a frame is complete, you just have to decode it using traditional methods, and everything rolls on. Don't know if you're interested in those news though, but it might be useful if some liveMedia users want to do the same as me :) Best regards, Guillaume. Le 07/09/2010 08:47, Ross Finlayson a ?crit : >> This video has (on purpose) no audio track, so I can focus on video >> stream only. >> Payload of value 32 is an MPEG1 or MPEG2 video > > That's correct. > > An important thing to note about the RTP payload format for MPEG-1 or > MPEG-2 video (defined in RFC 2250) is that the data units delivered by > RTP are not (necessarily) complete video frames (even though our code > refers to them as 'frames' - which is admittedly a bit confusing). > For MPEG-1 or 2 video, the data units delivered by RTP - i.e., > delivered one-at-a-time by a "MPEG1or2VideoRTPSource" object - can be > MPEG headers, or one or more video 'slices', but need not be a > complete video frame. (See RFC 2250 section 3.1 and Appendix 1.) This > allows a decoder to handle data loss without necessarily discarding an > entire video frame, but also means that it has to be a little smarter > about properly detecting when it has received enough data to make up > an entire frame. -- Guillaume FERRY Bertin Technologies D?partement Bertin Conseil Activit? Traitement de l'Information et du Contenu /T?l/ 01.39.30.62.09 /Fax/ 01.39.30.62.45 /Mail/ ferry at bertin.fr /Web/ www.bertin.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From arang1978 at gmail.com Sun Sep 12 21:53:28 2010 From: arang1978 at gmail.com (Aranganathan Sankaradoss) Date: Mon, 13 Sep 2010 13:53:28 +0900 Subject: [Live-devel] network disconnection notification in openRTSP Message-ID: hello Sir, I checked my doubt in the previous threads of discussion. I couldn't find it. So I am sending my doubts to you. When I start openRTSP, if there is no network connection, is it possible to keep checking the server status without exiting the openRTSP? If I disconnect the internet, while openRTSP is receiving the data from server, then program exits after 10 minutes. Is there any way to get immediate notification after the disconnection of internet in RTSP Client? Regards, Arang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamildobk at poczta.onet.pl Mon Sep 13 02:54:28 2010 From: kamildobk at poczta.onet.pl (Kamil Dobkowski) Date: Mon, 13 Sep 2010 11:54:28 +0200 Subject: [Live-devel] Problems with MediaSession::initiateByMediaType() Message-ID: <26D4D73EB5644FBEA247E0E7ADE6E630@KamilPC> Hi, I noticed a strange effect when calling initiateByMediaType() more than once during session setup. In my application I call setup methods in the following order: ... pSession->initiateByMediaType( "video/H264" ); pClient->setupMediaSubsession(); pSession->initiateByMediaType( "audio/PCMU" ); pClient->setupMediaSubsession(); pClient->playMediaSession(); ... and the problem is that during the first call an audio session is initiated, its session socket is created and a local port is stored in fClientPortNum - but immediately after that this session is deinitiated ( as it is not "video/H264" ), and all sockets are closed. In the next step a video session is initiated and the system assigns exactly the same port to it ( it is ok because all previously open sockets are already closed ). When I call initiateByMediaType( "audio/PCMU" ) an audio session is initiated once again, but now it binds explicitly to fClientPortNum which is the same port as used in a video session ! The system has no problem with it as SO_REUSEADDR is set on both sockets ( and Windows allows multiple sockets to be bound to one address, which is slightly different behaviour as in Unix, I think ), Windows delivers all incoming packets only to one of these sockets, so I hear no audio ( or I see no video ). It happens occasionally, but it is dangerous as everything looks ok, no errors are returned while, in fact, one media session is idle. Regards, Kamil Dobkowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From oshikztrego at hotmail.com Mon Sep 13 04:54:27 2010 From: oshikztrego at hotmail.com (Oshi Keren-Zur) Date: Mon, 13 Sep 2010 11:54:27 +0000 (UTC) Subject: [Live-devel] Streaming h264 MPEG-2 TS References: Message-ID: Ross Finlayson writes: > > At 6:05 PM +0300 9/7/10, oshikztrego at ... wrote: > >Hi, > >We are developing a linux based embedded device which functions as a > >streaming server. > > Do "we" not have our own domain name? (People who use hobbyist > email addresses (@hotmail, @gmail, @yahoo, etc.) are taken less > seriously on this mailing list.) OK, I will change this on future threads. Thanks for answering seriously so far. > >The device has a video encoder which produces h264 MPEG-4 Elementary > >Stream, Audio encoder, and closed caption source. > >Our project started off with the requirement to stream the Video by > >RTP. We used liveMedia for this. > > > >As the project evolved additional requirements/limitations were added: > >1. Offline streaming of previously captured data with trick-play > >2. The Streaming client can only play MPEG-2 ts. > > > >After some research regarding extending our use of liveMedia to > >satisfy these requirements, > >We reached the conclusion that using liveMedia as it is currently > >implemented will be difficult since > > > >1. Multiplexing of h.264, audio and closed captions to an MPEG-2 ts > >is not supported > > We *do* support multiplexing video (including H.264) and audio into a > MPEG-2 Transport Stream - using the > "MPEG2TransportStreamFromESSource" class. You might also be able to > modify this class to support closed captions. Sorry, my conclusion was much too general (and wrong). I will try to describe the problem better: The system is required to support multiple unicast streams of the same live/recorded video ( resuseFirstSource = True). I managed to use the "MPEG2TransportStreamFromESSource" class in order to multiplex the video in MPEG-2 ts, and used "testOnDemandRTSPServer" to stream to a vlc client. >From the second connection on,vlc complains about "Waiting for PPS/SPS unit". >From the mailing list I learnt that using "sprop_parameter_sets_str" of "H264VideoRTPSink::createNew()" is intended for use to provide the client with the correct PPS and SPS NAL units. However, If I understand correctly, no object of the "H264VideoRTPSink" is used when streaming an MPEG-2 Transport Stream. I did not manage to understand how to overcome this contradiction. What am I missing? Thanks, Oshi From psommerfeld at gmail.com Mon Sep 13 12:58:24 2010 From: psommerfeld at gmail.com (Peter Sommerfeld) Date: Mon, 13 Sep 2010 15:58:24 -0400 Subject: [Live-devel] Multi-channel streaming? Message-ID: Hi, I'm just wondering if live555 supports streaming multi-channel (two or more unique) video streams? If so, can one stream be, say, H.264 and the other MPEG-4? Thanks, Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 13 15:02:52 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 13 Sep 2010 15:02:52 -0700 Subject: [Live-devel] Close specified client by IP In-Reply-To: <68D227E48F4B0F4EB6161523402601BE7C07AE@PEKW987A.cn001.siemens.net> References: <68D227E48F4B0F4EB6161523402601BE7C07AE@PEKW987A.cn001.siemens.net> Message-ID: >I have written a control panel to control Live555 VOD server, in >this panel, administrator could see active connection's IP >addresses, I want to close some specified connections by IP address, >now the RTSPServer can receive these specified IP addresses, but how >could I close these connections in RTSPServer.cpp? You can cleanly close a connection - within the "RTSPServer" - simply by deleting its "RTSPClientSession" object. Therefore, all you need is a way of mapping "client IP address"+"client port number" to "RTSPClientSession". (Note that just knowing the client's IP address is not enough, because it's possible for more than one connection to come from the same IP address. You will need to use the client's port number as well.) I suggest that you subclass "RTSPServer" to add a hash table that maps "client IP address"+"client port number" to "RTSPClientSession". Redefine the "createNewClientSession()" virtual function to add an entry into this hash table each time that you create a new "RTSPClientSession" object. Also, whenever you delete a "RTSPClientSession" object (to close its connection), remove the corresponding hash table entry. As always, you should be able to do this just via subclassing - without modifying any of the supplied "LIVE555" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 13 16:44:25 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 13 Sep 2010 16:44:25 -0700 Subject: [Live-devel] Multi-channel streaming? In-Reply-To: References: Message-ID: >I'm just wondering if live555 supports streaming multi-channel (two >or more unique) video streams? If so, can one stream be, say, H.264 >and the other MPEG-4? Yes, we support that - at both the server and client ends - provided that the different (sub)streams use different RTP port numbers. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Sep 13 16:45:49 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 13 Sep 2010 16:45:49 -0700 Subject: [Live-devel] network disconnection notification in openRTSP In-Reply-To: References: Message-ID: >When I start openRTSP, if there is no network connection, is it >possible to keep checking the server status without exiting the >openRTSP? No. However you could, of course, run "openRTSP" multiple times, within a loop (in your command shell). >If I disconnect the internet, while openRTSP is receiving the data >from server, then program exits after 10 minutes. Is there any way >to get immediate notification after the disconnection of internet in >RTSP Client? No. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Sep 13 16:51:33 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 13 Sep 2010 16:51:33 -0700 Subject: [Live-devel] Problems with MediaSession::initiateByMediaType() In-Reply-To: <26D4D73EB5644FBEA247E0E7ADE6E630@KamilPC> References: <26D4D73EB5644FBEA247E0E7ADE6E630@KamilPC> Message-ID: >I noticed a strange effect when calling initiateByMediaType() more >than once during session setup. That happens because you're trying to use "initiateByMediaType()" in a way in which was not intended. (It was intended to be used to play a single subsession only.) >In my application I call setup methods in the following order: > >... >pSession->initiateByMediaType( "video/H264" ); >pClient->setupMediaSubsession(); >pSession->initiateByMediaType( "audio/PCMU" ); >pClient->setupMediaSubsession(); >pClient->playMediaSession(); Instead of doing this, I suggest iterating through the whole set of "MediaSubsession"s, checking each subsession's "mediumName()" and "codecName()", and then calling "initiate()" only on the subsessions that you want. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 13 17:38:47 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 13 Sep 2010 17:38:47 -0700 Subject: [Live-devel] Streaming h264 MPEG-2 TS In-Reply-To: References: Message-ID: >Sorry, my conclusion was much too general (and wrong). I will try to describe >the problem better: > >The system is required to support multiple unicast streams of the same >live/recorded video ( resuseFirstSource = True). OK, that's a significant piece of information. See below. >I managed to use the "MPEG2TransportStreamFromESSource" class in order to >multiplex the video in MPEG-2 ts, and used "testOnDemandRTSPServer" to stream >to a vlc client. >>From the second connection on,vlc complains about "Waiting for PPS/SPS unit". OK, now I know what your problem is. The H.264 Video Elementary Stream data that you are using for input contains PPS/SPS NAL units - but apparently they occur only at the start of the stream. Because you are using the same input stream for all clients (i.e., "reuseFirstSource = True"), only the first client will get to see these PPS/SPS NAL units. Therefore you will need to modify your H.264 Video Elementary Stream so that it repeats the PPS/SPS NAL units periodically (e.g., every 10 seconds). (These NAL units are usually very small, so there will be little overhead in doing this.) > >From the mailing list I learnt that using "sprop_parameter_sets_str" >of "H264VideoRTPSink::createNew()" is intended for use to provide the client >with the correct PPS and SPS NAL units. >However, If I understand correctly, no object of the >"H264VideoRTPSink" is used >when streaming an MPEG-2 Transport Stream. That's correct. When streaming a MPEG Transport Stream via RTP, a "SimpleRTPSink" object is used. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From smlee at acts29.co.kr Tue Sep 14 00:41:49 2010 From: smlee at acts29.co.kr (Seung-Min Lee) Date: Tue, 14 Sep 2010 16:41:49 +0900 Subject: [Live-devel] Support for the "LIVE555 Streaming Media" Message-ID: Dear Supporter I am an Android developer and I need support on playing video issue. Current development environment: - RTSP server: Live555 Media server - Mobile device: Samsung Galaxy S (SHW-M110S) or Galaxy K (SHW-M130K) or Galaxy Tab (platform: Android 2.1) I am trying to play video on mobile device mentioned above using Live 555 server. However with stream server that supports RTSP and HTTP protocol, video is played well but not on Live 555 server (I am getting ?format not supported? error message). I am guessing Live 555 server only supports RTSP protocol (so called complete RTSP) thus video is not displayed on these devices. Please provide all possible solutions for the issue and also provide open API that can be applied for the devices if it exists. If you need any further information, please let me know. Thank you for your support in advance Best Regards Seung-Min -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 14 01:15:54 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Sep 2010 01:15:54 -0700 Subject: [Live-devel] Support for the "LIVE555 Streaming Media" In-Reply-To: References: Message-ID: >I am trying to play video on mobile device mentioned above using >Live 555 server. However with stream server that supports RTSP and >HTTP protocol, video is played well but not on Live 555 server (I am >getting "format not supported" error message). > > > >I am guessing Live 555 server only supports RTSP protocol (so called >complete RTSP) thus video is not displayed on these devices. Our RTSP server implementation (including the "LIVE555 Media Server" product) currently supports standard RTSP/RTP (including both RTP-over-UDP and RTP-over-TCP), but does not (yet) support Apple's RTSP/RTP-over-HTTP tunneling protocol. However, if your RTSP client (mobile phone application) supports standard RTSP/RTP (over UDP or TCP), then it should be able to work with the "LIVE555 Media Server", provided that there is not a firewall inbetween that is blocking port 8554 (or port 554 if the server is run as 'root'). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Arnab.Samanta at symphonysv.com Tue Sep 14 03:00:20 2010 From: Arnab.Samanta at symphonysv.com (Arnab Samanta) Date: Tue, 14 Sep 2010 15:30:20 +0530 Subject: [Live-devel] how to configure jitter in live555 Message-ID: <0F5FCFC9A064004DA46F28981BB330C4012BE7EA1A6C@BLR2K7EXCL01.symphonysv.com> Hello All, Please tell me how do I configure various paramerters of jitter in LIVE555. Regards, Arnab "This email and any files transmitted with it contain confidential, proprietary, privileged information of Symphony Services Corp (India) Pvt. Ltd. and are intended solely for the use of the recipient/s to whom it is addressed. Any unauthorized notifying, copying or distributing of this e-mail, directly or indirectly, and the contents therein in full or part is prohibited by any entity who is not a recipient. Any email received inadvertently or by mistake should be deleted by the entity who is not a recipient thereof. You may be pleased to notify the sender immediately by email and the email should be deleted from your system". -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 14 07:30:45 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Sep 2010 07:30:45 -0700 Subject: [Live-devel] how to configure jitter in live555 In-Reply-To: <0F5FCFC9A064004DA46F28981BB330C4012BE7EA1A6C@BLR2K7EXCL01.symphonysv.com> References: <0F5FCFC9A064004DA46F28981BB330C4012BE7EA1A6C@BLR2K7EXCL01.symphonysv.com> Message-ID: >Please tell me how do I configure various paramerters of jitter in LIVE555. You don't. "Jitter" is a property of the network. It's something that you measure; not something that you "configure". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jtam at ivcco.com Tue Sep 14 08:44:37 2010 From: jtam at ivcco.com (John Tam) Date: Tue, 14 Sep 2010 10:44:37 -0500 Subject: [Live-devel] Graceful handling of socket error In-Reply-To: References: , <5596F629427ED04B8D07502DE0500E6925787BE397@AUSP01VMBX29.collaborationhost .net>, Message-ID: <5596F629427ED04B8D07502DE0500E6925787BE39B@AUSP01VMBX29.collaborationhost.net> Ross, Thank you for your advise. My bad on the 10038 error in particular in which I torn down the client session while trying to manage these sessions. Of course, I hope the previously proposed change to replace the call to abort() is still moving forward. Regards, John Tam ________________________________________ ???: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] ?? Ross Finlayson [finlayson at live555.com] ????: Thursday, 9 September, 2010 3:33 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] Graceful handling of socket error >To answer your earlier question, I get error code 10038 on Windows This is "ENOTSOCK", which indicates that one of the sockets specified in the "select()" call was not actually a socket - either because it had not actually been created, or because it had already been closed. This indicates a bug somewhere, because our code is supposed to be calling "turnOnBackgroundReadHandling()" only on actual sockets, and calling "turnOffBackgroundReadHandling()" on every socket before it gets closed. It would be nice to figure out this bug... -- 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 Arnab.Samanta at symphonysv.com Tue Sep 14 22:29:28 2010 From: Arnab.Samanta at symphonysv.com (Arnab Samanta) Date: Wed, 15 Sep 2010 10:59:28 +0530 Subject: [Live-devel] how to configure jitter in live555 In-Reply-To: References: <0F5FCFC9A064004DA46F28981BB330C4012BE7EA1A6C@BLR2K7EXCL01.symphonysv.com> Message-ID: <0F5FCFC9A064004DA46F28981BB330C4012BE7EA1B02@BLR2K7EXCL01.symphonysv.com> Thanks Ross. Is there any jitter buffer implemented in live555 ? If YES, then how can I configure its parameters ? Regards, Arnab -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, September 14, 2010 8:01 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] how to configure jitter in live555 >Please tell me how do I configure various paramerters of jitter in LIVE555. You don't. "Jitter" is a property of the network. It's something that you measure; not something that you "configure". -- 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 "This email and any files transmitted with it contain confidential, proprietary, privileged information of Symphony Services Corp (India) Pvt. Ltd. and are intended solely for the use of the recipient/s to whom it is addressed. Any unauthorized notifying, copying or distributing of this e-mail, directly or indirectly, and the contents therein in full or part is prohibited by any entity who is not a recipient. Any email received inadvertently or by mistake should be deleted by the entity who is not a recipient thereof. You may be pleased to notify the sender immediately by email and the email should be deleted from your system". From finlayson at live555.com Wed Sep 15 01:08:18 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Sep 2010 01:08:18 -0700 Subject: [Live-devel] how to configure jitter in live555 In-Reply-To: <0F5FCFC9A064004DA46F28981BB330C4012BE7EA1B02@BLR2K7EXCL01.symphonysv.com> References: <0F5FCFC9A064004DA46F28981BB330C4012BE7EA1A6C@BLR2K7EXCL01.symphonysv.com> <0F5FCFC9A064004DA46F28981BB330C4012BE7EA1B02@BLR2K7EXCL01.symphonysv.com> Message-ID: >Is there any jitter buffer implemented in live555 ? No (mainly because jitter buffers tend to be highly application-specific). It's up to each client implementation to implement a jitter buffer (or not) however it pleases, using the provided "presentation time" values for each received chunk of data. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yinhua.li at siemens.com Wed Sep 15 01:26:04 2010 From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S) Date: Wed, 15 Sep 2010 16:26:04 +0800 Subject: [Live-devel] Close specified client by IP In-Reply-To: References: <68D227E48F4B0F4EB6161523402601BE7C07AE@PEKW987A.cn001.siemens.net> Message-ID: <68D227E48F4B0F4EB6161523402601BE7EC429@PEKW987A.cn001.siemens.net> Thanks Ross, I just want to close client connection by IP address and not consider port number, because in our project not allowed more than one connection from the same IP address. After reading your reply, I'm sorry that I still don't know how to do this. I just got the client IP address that would be closed, according to your suggestion I must find the clientsession first, but how can I find its clientsession by this IP address? ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, September 14, 2010 6:03 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Close specified client by IP I have written a control panel to control Live555 VOD server, in this panel, administrator could see active connection's IP addresses, I want to close some specified connections by IP address, now the RTSPServer can receive these specified IP addresses, but how could I close these connections in RTSPServer.cpp? You can cleanly close a connection - within the "RTSPServer" - simply by deleting its "RTSPClientSession" object. Therefore, all you need is a way of mapping "client IP address"+"client port number" to "RTSPClientSession". (Note that just knowing the client's IP address is not enough, because it's possible for more than one connection to come from the same IP address. You will need to use the client's port number as well.) I suggest that you subclass "RTSPServer" to add a hash table that maps "client IP address"+"client port number" to "RTSPClientSession". Redefine the "createNewClientSession()" virtual function to add an entry into this hash table each time that you create a new "RTSPClientSession" object. Also, whenever you delete a "RTSPClientSession" object (to close its connection), remove the corresponding hash table entry. As always, you should be able to do this just via subclassing - without modifying any of the supplied "LIVE555" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person. In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk ????:???????????,???????????????????????????,????????????,?????????????????????????????????????,?????????????????????????????? ?????????????????,?????????????????,????????????"Tell us"??,???www.siemens.com.cn/compliancehelpdesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 15 12:31:23 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Sep 2010 12:31:23 -0700 Subject: [Live-devel] Close specified client by IP In-Reply-To: <68D227E48F4B0F4EB6161523402601BE7EC429@PEKW987A.cn001.siemens.net> References: <68D227E48F4B0F4EB6161523402601BE7C07AE@PEKW987A.cn001.siemens.net> <68D227E48F4B0F4EB6161523402601BE7EC429@PEKW987A.cn001.siemens.net> Message-ID: >Thanks Ross, I just want to close client connection by IP address >and not consider port number, because in our project not allowed >more than one connection from the same IP address. After reading >your reply, I'm sorry that I still don't know how to do this. I just >got the client IP address that would be closed, according to your >suggestion I must find the clientsession first, but how can I >find its clientsession by this IP address? Once again: I suggest that you subclass "RTSPServer" to add a hash table that maps "client IP address" to "RTSPClientSession". Redefine the "createNewClientSession()" virtual function to add an entry into this hash table each time that you create a new "RTSPClientSession" object. Also, whenever you delete a "RTSPClientSession" object (to close its connection), remove the corresponding hash table entry. As always, you should be able to do this just via subclassing - without modifying any of the supplied "LIVE555" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinhua.li at siemens.com Wed Sep 15 22:58:21 2010 From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S) Date: Thu, 16 Sep 2010 13:58:21 +0800 Subject: [Live-devel] Close specified client by IP In-Reply-To: References: <68D227E48F4B0F4EB6161523402601BE7C07AE@PEKW987A.cn001.siemens.net><68D227E48F4B0F4EB6161523402601BE7EC429@PEKW987A.cn001.siemens.net> Message-ID: <68D227E48F4B0F4EB6161523402601BE7EC71F@PEKW987A.cn001.siemens.net> It works, thanks Ross! ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, September 16, 2010 3:31 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Close specified client by IP Thanks Ross, I just want to close client connection by IP address and not consider port number, because in our project not allowed more than one connection from the same IP address. After reading your reply, I'm sorry that I still don't know how to do this. I just got the client IP address that would be closed, according to your suggestion I must find the clientsession first, but how can I find its clientsession by this IP address? Once again: I suggest that you subclass "RTSPServer" to add a hash table that maps "client IP address" to "RTSPClientSession". Redefine the "createNewClientSession()" virtual function to add an entry into this hash table each time that you create a new "RTSPClientSession" object. Also, whenever you delete a "RTSPClientSession" object (to close its connection), remove the corresponding hash table entry. As always, you should be able to do this just via subclassing - without modifying any of the supplied "LIVE555" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person. In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk ????:???????????,???????????????????????????,????????????,?????????????????????????????????????,?????????????????????????????? ?????????????????,?????????????????,????????????"Tell us"??,???www.siemens.com.cn/compliancehelpdesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From zdenek at next-stream.com Sun Sep 19 04:43:02 2010 From: zdenek at next-stream.com (Zdenek Bouresh) Date: Sun, 19 Sep 2010 14:43:02 +0300 Subject: [Live-devel] Many multicast sources with same port problem Message-ID: Hi Ross, thank you for this nice library. I am very new to C++, but thanks to your GAQ and mailing list I was able to put together an application that receives from many live sources, reuses first source and streams unicast on demand to many clients. I even got myslq integrated and get the list of sources from database. Great! So far so good. One problem that I spent a lot of time to debug is if multicast sources have the same port. In this case when I open different sources they act strangely and start overlapping, switching randomly source , even if the client stays on the exact same connection. He gets many sources switched to him in the UDP stream. (input is mixed up, affecting output, no matter if reuse or not) Then I found somewhere in this list you mentioning that this is a big on some Linux flavors, and we should use different ports to avoid. Problem is I cannot use different ports, I have 100+ multicast sources, all with same port but different address. And in theory its a different source address, port should not matter or mix right ? Also I have used many other utilities, on the same systems and they don't have this "big" or behavior, hence I don't believe its an OS bug, since I have tried on a number of Linux flavors, including the latest releases. If all other software works, my only guess is that it has be a problem in the groupsock. I really need a way around this. Your thoughts ? P.S Also how do we get around the 16 simultaneous connections limit problem. I know this is an os setting (for the max open file descriptors???) , but is there a code or method we can use from within the library or application to ensure we set it high like 1024 or something ? Thanks You Help greatly appreciated and please excuse me if this has been discussed or solved elsewhere, I really looked and searched and read the whole mailing list from day one. Zed -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Sep 19 05:12:17 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 19 Sep 2010 05:12:17 -0700 Subject: [Live-devel] Many multicast sources with same port problem In-Reply-To: References: Message-ID: If your application is receiving - on a socket - traffic that was sent to a multicast address that that socket did not subscribe to, then that is definitely a problem with the operating system, not with your application, and not with our libraries. Because you say that you are unwilling to change your operating system[*], and because you say that you can't stop your incoming traffic (for different multicast addresses) from using distinct port numbers, then there's no help that I can give you. Sorry. [*] Note that FreeBSD - as far as I can tell - does not appear to have this problem. If I were you, I'd try using FreeBSD instead of Linux. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From zdenek at next-stream.com Sun Sep 19 06:57:35 2010 From: zdenek at next-stream.com (Zdenek Bouresh) Date: Sun, 19 Sep 2010 16:57:35 +0300 Subject: [Live-devel] Many multicast sources with same port problem In-Reply-To: References: Message-ID: Thanks Ross, I will try freeBSD and report back. The part that I don't get is how do other apps don't get this problem on the same OS with the same input streams. 239.255.1.1:22334 239.255.1.2:22334 239.255.1.3:22334 All are recognized as different sources, since the combination of multicast IP and port is unique. They all subscribe to all addresses, but when reading the requested socket, they read the one selected on the port, not the others. >From what I understand you're saying that when live555 is requested to read on port 22334 of some source, traffic there is coming from all sources and not just the requested. Again, I dont get it, how do other apps work if this be the case. Its this that leads me to believe that even if there is an OS problem, there is some way around it in code. Thanks again, Appreciate your time. I will try freeBSD. Zed. On Sun, Sep 19, 2010 at 3:12 PM, Ross Finlayson wrote: > If your application is receiving - on a socket - traffic that was sent to a > multicast address that that socket did not subscribe to, then that is > definitely a problem with the operating system, not with your application, > and not with our libraries. > > Because you say that you are unwilling to change your operating system[*], > and because you say that you can't stop your incoming traffic (for different > multicast addresses) from using distinct port numbers, then there's no help > that I can give you. Sorry. > > [*] Note that FreeBSD - as far as I can tell - does not appear to have this > problem. If I were you, I'd try using FreeBSD instead of Linux. > -- > > 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 > -- Zdenek Bouresh NextStream LTD. The information contained within this email transmission and any attachments is confidential and intended solely for the attention and use of the named individual addressee(s) or entity. It may not be legally revealed or be disclosed to any other person or third party without the express authority (prior written approval) of NextStream LTD and/or the original recipient, or the intended recipients, or both. If you are not the intended recipient, you must not disclose, copy, distribute, print, rely on or retain this message or any part of it. The information contained within is strictly prohibited. If you have received this email in error please notify the sender by reply, and delete this message from your email system(s). Any hard copies must also be destroyed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zdenek at next-stream.com Sun Sep 19 08:23:34 2010 From: zdenek at next-stream.com (Zdenek Bouresh) Date: Sun, 19 Sep 2010 18:23:34 +0300 Subject: [Live-devel] Many multicast sources with same port problem In-Reply-To: References: Message-ID: OK, I dug a little and kind of found the answer why it works without a kernel patch The apps that worked actually use bind() which is not the right way to do it, but it seems to work, both on linux and bsd. Someone posted an example here for an older version of the lib as a workaround solution. http://www.mail-archive.com/live-devel at lists.live555.com/msg02194.html What would the workaround be if I want to temporally patch the lib as it is today so it works ? A see there is an IF for WIN, is there a way to make such a workaround for linux and what would the code be. Sorry, I am a bit of C++ beginner when it comes to the library stuff. Needles to say its hard to patch every kernel that comes with every distro packaged and gets updated every 2 weeks Most people ise stock distro provided kernel, patching it is quite an effort. Also why is this patch still not in the latest production kernels. I don't get it. Its a known issue, patches provided, why not in yet ? While I do agree the OS is broken so is Windows, is there a way to test this and if the bug exists apply a workaround. I am sure the biggest percentage of people use this lib under Linux. Zed On Sun, Sep 19, 2010 at 4:57 PM, Zdenek Bouresh wrote: > Thanks Ross, > I will try freeBSD and report back. > > The part that I don't get is how do other apps don't get this problem on > the same OS with the same input streams. > 239.255.1.1:22334 > 239.255.1.2:22334 > 239.255.1.3:22334 > > All are recognized as different sources, since the combination of multicast > IP and port is unique. > They all subscribe to all addresses, but when reading the requested socket, > they read the one selected on the port, not the others. > > From what I understand you're saying that when live555 is requested to read > on port 22334 of some source, traffic there is coming from all sources and > not just the requested. > > Again, I dont get it, how do other apps work if this be the case. > Its this that leads me to believe that even if there is an OS problem, > there is some way around it in code. > > Thanks again, > Appreciate your time. > I will try freeBSD. > > Zed. > > On Sun, Sep 19, 2010 at 3:12 PM, Ross Finlayson wrote: > >> If your application is receiving - on a socket - traffic that was sent to >> a multicast address that that socket did not subscribe to, then that is >> definitely a problem with the operating system, not with your application, >> and not with our libraries. >> >> Because you say that you are unwilling to change your operating system[*], >> and because you say that you can't stop your incoming traffic (for different >> multicast addresses) from using distinct port numbers, then there's no help >> that I can give you. Sorry. >> >> [*] Note that FreeBSD - as far as I can tell - does not appear to have >> this problem. If I were you, I'd try using FreeBSD instead of Linux. >> -- >> >> 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 >> > > > > -- > Zdenek Bouresh > NextStream LTD. > > The information contained within this email transmission and any > attachments is confidential and intended solely for the attention and use of > the named individual addressee(s) or entity. It may not be legally revealed > or be disclosed to any other person or third party without the express > authority (prior written approval) of NextStream LTD and/or the original > recipient, or the intended recipients, or both. If you are not the intended > recipient, you must not disclose, copy, distribute, print, rely on or retain > this message or any part of it. The information contained within is strictly > prohibited. If you have received this email in error please notify the > sender by reply, and delete this message from your email system(s). Any hard > copies must also be destroyed. > -- Zdenek Bouresh NextStream LTD. The information contained within this email transmission and any attachments is confidential and intended solely for the attention and use of the named individual addressee(s) or entity. It may not be legally revealed or be disclosed to any other person or third party without the express authority (prior written approval) of NextStream LTD and/or the original recipient, or the intended recipients, or both. If you are not the intended recipient, you must not disclose, copy, distribute, print, rely on or retain this message or any part of it. The information contained within is strictly prohibited. If you have received this email in error please notify the sender by reply, and delete this message from your email system(s). Any hard copies must also be destroyed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Sep 19 08:35:48 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 19 Sep 2010 08:35:48 -0700 Subject: [Live-devel] Many multicast sources with same port problem In-Reply-To: References: Message-ID: >Someone posted an example here for an older version of the lib as a >workaround solution. >http://www.mail-archive.com/live-devel at lists.live555.com/msg02194.html Then I hope you also read my follow-up to that message: http://www.mail-archive.com/live-devel at lists.live555.com/msg02195.html You should fix the bug in your OS kernel. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferry at bertin.fr Mon Sep 20 09:29:43 2010 From: ferry at bertin.fr (Guillaume Ferry) Date: Mon, 20 Sep 2010 18:29:43 +0200 Subject: [Live-devel] Asynchronous API - Subclassing troubles Message-ID: <4C978BF7.5060705@bertin.fr> Hi Ross, I'm currently updating our RTSP client (based on liveMedia), to use your asynchronous API. The client is being used within a simple GTK application, so as you mentioned in the FAQ, I have to subclass to use GTK's event loop instead of your native loop. So I did a simple subclass of BasicTaskScheduler, that I named EventScheduler. The only method I'm re-implementing is 'doEventLoop', so I can let GTK event loop handle the 'SingleStep' calls. It works fine for the first call (DESCRIBE), but after then, it crashes...I provided you a backtrace afterwards. I'm pretty sure I've made a wrong (or incomplete) subclass, but I tried to match openRTSP source as close as possible. By the way, when I replace my custom TaskScheduler by the basic one (BasicTaskScheduler), problem still occurs. Thanks for you insights ! Best regards, Guillaume. PS : I'm using the latest liveMedia sources (2010.09.10) **** BackTrace **** #0 0x080882af in _Tables::getOurTables(UsageEnvironment&, unsigned int) () #1 0x080883b2 in MediaLookupTable::ourMedia(UsageEnvironment&) () #2 0x08088580 in Medium::Medium(UsageEnvironment&) () #3 0x0808bec8 in MediaSession::MediaSession(UsageEnvironment&) () #4 0x0808bf8b in MediaSession::createNew(UsageEnvironment&, char const*) () #5 0x08081307 in RTSPSession::createSession (this=0x818c9c0) at /home/ferry/Dev/svn/transcriber/mmTag/source/src/MediaComponent/rtsp/RTSPSession.cpp:72 #6 0x08081e65 in afterDESCRIBE (cli=0x818c9c0, rc=0, resultString=0x8196ce8 "v=0\r\no=- 1284999509917742 1 IN IP4 127.0.1.1\r\ns=MPEG-1 or 2 Audio, streamed by MultimediaRTSPServer\r\ni=audio:blessed.mp3\r\nt=0 0\r\na=tool:LIVE555 Streaming Media v2010.09.10\r\na=type:broadcast\r\na=control"...) at /home/ferry/Dev/svn/transcriber/mmTag/source/src/MediaComponent/rtsp/RTSPSession.cpp:457 #7 0x0809f4d5 in RTSPClient::handleResponseBytes(int) () #8 0x0809ffab in RTSPClient::incomingDataHandler1() () #9 0x080a833b in BasicTaskScheduler::SingleStep(unsigned int) () #10 0x0808518e in EventScheduler::advance (this=0x818c400) at /home/ferry/Dev/svn/transcriber/mmTag/source/src/MediaComponent/rtsp/EventScheduler.cpp:37 **** BackTrace End **** -- Guillaume FERRY Bertin Technologies D?partement Bertin Conseil Activit? Traitement de l'Information et du Contenu /T?l/ 01.39.30.62.09 /Fax/ 01.39.30.62.45 /Mail/ ferry at bertin.fr /Web/ www.bertin.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 20 10:44:39 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Sep 2010 11:44:39 -0600 Subject: [Live-devel] Asynchronous API - Subclassing troubles In-Reply-To: <4C978BF7.5060705@bertin.fr> References: <4C978BF7.5060705@bertin.fr> Message-ID: >**** BackTrace **** > >#0 0x080882af in _Tables::getOurTables(UsageEnvironment&, unsigned int) () The fact that you're seeing a crash in such an innocuous function suggests to me that you may be linking with old binaries somewhere. (I assume that you're not doing something stupid like trying to access the library from multiple threads.) So, my first suggestion would be to remove all of your binaries, and then recompile/relink everything from scratch. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From zdenek at next-stream.com Mon Sep 20 15:12:50 2010 From: zdenek at next-stream.com (Zdenek Bouresh) Date: Tue, 21 Sep 2010 01:12:50 +0300 Subject: [Live-devel] Many multicast sources with same port problem In-Reply-To: References: Message-ID: OK, here is a little feedback, just tried this on OS X 10.5, same behavior, sources mix if on same port. With all due respect, its rather strange that all Linux Kernels (2.4 and 2.6), Windows and OS X (which is somewhat BSD based) are all broken, an the theory is that only freeBSD works and everyone should switch to that. BTW:The patch provided is for Kernel 2.4. There must be some other way. I could accept linux broken,but OS X ? Does not make sense and even if you are right, there ought to be a solution in software we should have to overcome this. Its not like its only one OS or one network stack. Its the majority. Zed On Sun, Sep 19, 2010 at 8:18 PM, Zdenek Bouresh wrote: > I did and I understand this. > However it is not always possible. > So I am looking for a workaround, until this gets solved permanently in the > modern distros and kernels. > Zed > > On Sun, Sep 19, 2010 at 6:35 PM, Ross Finlayson wrote: > >> Someone posted an example here for an older version of the lib as a >> workaround solution. >> >> http://www.mail-archive.com/live-devel at lists.live555.com/msg02194.html >> >> >> Then I hope you also read my follow-up to that message: >> >> http://www.mail-archive.com/live-devel at lists.live555.com/msg02195.html >> >> You should fix the bug in your OS kernel. >> >> -- >> >> >> Ross Finlayson >> Live Networks, Inc. >> http://www.live555.com/ >> >> _______________________________________________ >> live-devel mailing list >> >> live-devel at lists.live555.com >> http://lists.live555.com/mailman/listinfo/live-devel >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 20 23:29:30 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 21 Sep 2010 00:29:30 -0600 Subject: [Live-devel] Many multicast sources with same port problem In-Reply-To: References: Message-ID: >OK, >here is a little feedback, just tried this on OS X 10.5, >same behavior, sources mix if on same port. > >With all due respect, its rather strange that all Linux Kernels (2.4 >and 2.6), Windows and OS X (which is somewhat BSD based) are all >broken OK, so the problem with your application is apparently not due to the OS multicast bug after all. This has been a 'wild goose chase'. Because your problem seems to occur only with your application, I'm not going to waste any more of my time (or the mailing list's time) on this anymore. We can't help people with their own application-specific problems. Sorry. This topic is now closed. From ferry at bertin.fr Tue Sep 21 06:54:39 2010 From: ferry at bertin.fr (Guillaume Ferry) Date: Tue, 21 Sep 2010 15:54:39 +0200 Subject: [Live-devel] Asynchronous API - Subclassing troubles In-Reply-To: References: <4C978BF7.5060705@bertin.fr> Message-ID: <4C98B91F.6080205@bertin.fr> Le 20/09/2010 19:44, Ross Finlayson a ?crit : >> **** BackTrace **** >> >> #0 0x080882af in _Tables::getOurTables(UsageEnvironment&, unsigned >> int) () > > The fact that you're seeing a crash in such an innocuous function > suggests to me that you may be linking with old binaries somewhere. (I > assume that you're not doing something stupid like trying to access > the library from multiple threads.) > > So, my first suggestion would be to remove all of your binaries, and > then recompile/relink everything from scratch. Hi Ross, Thanks for assuming this :) Of course, I'm not using it in a multi-threaded context, right now, it is just a small sample application, launching one RTSP connection. I rebuilt all libs from scratch, but it still crashes. I'll dive into openRTSP code, because I must have missed something. I'll keep you in touch very soon. Best regards, Guillaume. -- Guillaume FERRY Bertin Technologies D?partement Bertin Conseil Activit? Traitement de l'Information et du Contenu /T?l/ 01.39.30.62.09 /Fax/ 01.39.30.62.45 /Mail/ ferry at bertin.fr /Web/ www.bertin.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Tue Sep 21 07:50:38 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Tue, 21 Sep 2010 16:50:38 +0200 Subject: [Live-devel] new API and callbacks Message-ID: <1285080638.10388.6.camel@sebastien-desktop> Hi, I am trying to adapt vlc to the live555 asynchronous API, and I have a question. Callbacks functions declaration is : typedef void (responseHandler)(RTSPClient* rtspClient, int resultCode, char* resultString); But how can I access my application data in this callback. Why the callback paramater does not have a void* user data parameter, like in (afterGettingFunc) for example ? Regards, Sebastien. From ivan.alen at uclouvain.be Tue Sep 21 08:11:27 2010 From: ivan.alen at uclouvain.be (Ivan Alen Fernandez) Date: Tue, 21 Sep 2010 17:11:27 +0200 Subject: [Live-devel] Error of the server running in Linux Message-ID: <208d2eac8099abaf8f217f7d114cceb7.squirrel@mmp.sipr-dc.ucl.ac.be> Hello, I am using the live555 to deliver rtp packets of H264 files in multiple concatenated small clips with an intelligent interaction under the user request. One xml file script is parsed every time to decide the next file to insert in the rtp sink. My implementation of the H264 framer, source and sink is done as proposed in the FAQ. My problem is that i have done lately some modifications in the class ByteStreamFileSource and for linux i have to run the player two times in order that the video starts playing and after 20 seconds or so the server exits with the next error: BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor In Windows with approximately the similar code, the clients receives well the packets at the first attempt and the server doesnt stop at any time. Can anyone suggest to me what is going wrong in linux (ubuntu) and why it doesnt work in that plattform while in windows there is no problem. Thanks a lot in advance for your help Ivan From wlm at tid.es Tue Sep 21 09:16:19 2010 From: wlm at tid.es (wlm) Date: Tue, 21 Sep 2010 18:16:19 +0200 Subject: [Live-devel] How to configure a virtual IP in the server and client Message-ID: <4C98DA53.70207@tid.es> Dear, I'm working in a project about IPTV, and I have configured in my network card two address IP (primary and secondary), but I need to modify the code RTSPserver as well as RTSPclient for that can it take both address primary and secondary. Thanks Best Regards William L?ligo Monsalve Telefonica R&D Spain From finlayson at live555.com Tue Sep 21 08:44:32 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 21 Sep 2010 09:44:32 -0600 Subject: [Live-devel] new API and callbacks In-Reply-To: <1285080638.10388.6.camel@sebastien-desktop> References: <1285080638.10388.6.camel@sebastien-desktop> Message-ID: >I am trying to adapt vlc to the live555 asynchronous API That's great - thanks! >, and I have a >question. >Callbacks functions declaration is : >typedef void (responseHandler)(RTSPClient* rtspClient, int resultCode, >char* resultString); > >But how can I access my application data in this callback. >Why the callback paramater does not have a void* user data parameter, >like in (afterGettingFunc) for example ? This question came up back in June, shortly after the new interface was introduced. This was my answer then: http://lists.live555.com/pipermail/live-devel/2010-June/012223.html Do you plan to have more than one "RTSPClient" object concurrently? If not, then you can just use a global variable. But if you do plan to have more than one "RTSPClient" object concurrently, then you can define a subclass, and add your 'application data' there. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Sep 21 10:47:47 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 21 Sep 2010 11:47:47 -0600 Subject: [Live-devel] Error of the server running in Linux In-Reply-To: <208d2eac8099abaf8f217f7d114cceb7.squirrel@mmp.sipr-dc.ucl.ac.be> References: <208d2eac8099abaf8f217f7d114cceb7.squirrel@mmp.sipr-dc.ucl.ac.be> Message-ID: >My problem is that i have done lately some modifications in the class >ByteStreamFileSource Rather than modifying the existing code, you should really define a *new* class (perhaps copying much of the existing code). That way, you can easily upgrade to new versions of the released LIVE555 library code. > and for linux i have to run the player two times in >order that the video starts playing and after 20 seconds or so the server >exits with the next error: > >BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor That error means that you closed a socket, but did not call "TaskScheduler:: turnOffBackgroundReadHandling()" beforehand. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sebastien-devel at celeos.eu Tue Sep 21 13:14:02 2010 From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier) Date: Tue, 21 Sep 2010 22:14:02 +0200 Subject: [Live-devel] new API and callbacks In-Reply-To: References: <1285080638.10388.6.camel@sebastien-desktop> Message-ID: <1285100042.4c99120aa883b@imp.celeos.eu> Selon Ross Finlayson : > Do you plan to have more than one "RTSPClient" object concurrently? > If not, then you can just use a global variable. But if you do plan > to have more than one "RTSPClient" object concurrently, then you can > define a subclass, and add your 'application data' there. Yes, there can be more than one RTSPClient object concurrently, so I'll have to subclass. Too bad, just for a variable. Thanks for your response. S?bastien. From md at bts.sk Wed Sep 22 00:41:28 2010 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Wed, 22 Sep 2010 09:41:28 +0200 Subject: [Live-devel] Bug in recent liveMedia affecting VLC In-Reply-To: <20100922064926.M68371@bts.sk> References: <20100922064926.M68371@bts.sk> Message-ID: <20100922074037.M89182@bts.sk> Hi, since some modifications to Transport: header parsing in liveMedia library, VLC refuses to talk RTSP with various webcams. More details here: http://trac.videolan.org/vlc/ticket/4129#comment:2 Could someone please have a look? Thanks & kind regards, M. From finlayson at live555.com Wed Sep 22 00:51:09 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 22 Sep 2010 01:51:09 -0600 Subject: [Live-devel] Bug in recent liveMedia affecting VLC In-Reply-To: <20100922074037.M89182@bts.sk> References: <20100922064926.M68371@bts.sk> <20100922074037.M89182@bts.sk> Message-ID: No, this is a bug in the RTSP server (webcam); not a bug in our code. The problem is the parameter field port=5000 This is nonstandard. The RTSP specification (RFC 2326, section 12.39) clearly states that the "port=" parameter (for multicast streams) should be specified as a range - e.g., "port=5000-5001". You should contact your server manufacturer, asking them to fix this bug. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From md at bts.sk Wed Sep 22 01:08:37 2010 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Wed, 22 Sep 2010 10:08:37 +0200 Subject: [Live-devel] Bug in recent liveMedia affecting VLC In-Reply-To: References: <20100922064926.M68371@bts.sk> <20100922074037.M89182@bts.sk> Message-ID: <20100922080104.M85080@bts.sk> On Wed, 22 Sep 2010 01:51:09 -0600, Ross Finlayson wrote > No, this is a bug in the RTSP server (webcam); not a bug in our code. > The problem is the parameter field > port=5000 > This is nonstandard. The RTSP specification (RFC 2326, section > 12.39) clearly states that the "port=" parameter (for multicast > streams) should be specified as a range - e.g., "port=5000-5001". Well, a few lines below this, the transport header "grammar" specifies: ";" "port" "=" port [ "-" port ] making the second port number clearly optional :-) Webcams typically only send media without RTCP, so this makes a lot of sense. And as usual, being liberal in what you accept is good thing. With kind regards, M. From finlayson at live555.com Wed Sep 22 03:18:59 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 22 Sep 2010 04:18:59 -0600 Subject: [Live-devel] Bug in recent liveMedia affecting VLC In-Reply-To: <20100922080104.M85080@bts.sk> References: <20100922064926.M68371@bts.sk> <20100922074037.M89182@bts.sk> <20100922080104.M85080@bts.sk> Message-ID: >On Wed, 22 Sep 2010 01:51:09 -0600, Ross Finlayson wrote >> No, this is a bug in the RTSP server (webcam); not a bug in our code. >> The problem is the parameter field >> port=5000 >> This is nonstandard. The RTSP specification (RFC 2326, section >> 12.39) clearly states that the "port=" parameter (for multicast >> streams) should be specified as a range - e.g., "port=5000-5001". > >Well, a few lines below this, the transport header "grammar" specifies: > >";" "port" "=" port [ "-" port ] > >making the second port number clearly optional :-) OK, the specification is ambiguous here. >Webcams typically only send media without RTCP No, that's not true. (By the way, RTCP is a mandatory part of the RTP/RTCP specification; any server (or client) that does not implement RTCP is non-standard.) >And as usual, being liberal in what you accept is good thing. Yes, and for this reason (especially given the ambiguity in the RTSP specification), I have now installed a new version (2010.09.22) that will accept both kinds of "port=" parameter. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From david.stegbauer at acision.com Wed Sep 22 03:19:32 2010 From: david.stegbauer at acision.com (David Stegbauer) Date: Wed, 22 Sep 2010 12:19:32 +0200 Subject: [Live-devel] live555MediaServer: RTP source address does not match RTSP source address Message-ID: <201009221219.32818.david.stegbauer@acision.com> Hello Ross, when I run live555MediaServer on linux, it listens on all network interfaces. Lets say I have two: 172.16.105.9 and 172.16.105.3. Lets suppose I start RTSP communication from RTSP client (openRTSP on 172.16.105.8) to server on 172.16.105.9. Client sends SETUP command, server responds and there is header Transport: RTP/AVP;unicast;destination=172.16.105.8;source=172.16.105.9;client_port=10004-10005;server_port=6970-6971 So far so good. But now in response to PLAY, the live555MediaServer starts to transmit RTP packets from interface 172.16.105.3. See attached dump, can be viewed by wireshark. I have analyzed the code and I think the problem is that the RTP source socket (in live555MediaServer) has INADDR_ANY. As a quick hack I have patched RTSPServer.cpp, see attachment. I know that the preferred way is to subclass, I do not ask for inclusion, I just ask for your advice. My questions are: Am I really supposed to set SendingInterfaceAddr and ReceivingInterfaceAddr (defined in GroupSockHelper.cpp lines 35-36)? Are there any undesirable interferences between RTSPServer::RTSPClientSession instances if I use my hack? I don't see any as live555 is not multithread. Do you suggest to me to subclass, to use the above mentioned hack, or even to modify GroupSockHelper.cpp (setupDatagramSocket, socketJoinGroup, socketJoinGroupSSM) and OnDemandServerMediaSubsession ::getStreamParameters? Best Regards David Stegbauer This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: dump_server Type: application/octet-stream Size: 49974 bytes Desc: dump_server URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rtspserver.diff Type: text/x-patch Size: 1416 bytes Desc: rtspserver.diff URL: From md at bts.sk Wed Sep 22 03:47:51 2010 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Wed, 22 Sep 2010 12:47:51 +0200 Subject: [Live-devel] Bug in recent liveMedia affecting VLC In-Reply-To: References: <20100922064926.M68371@bts.sk> <20100922074037.M89182@bts.sk> <20100922080104.M85080@bts.sk> Message-ID: <20100922104751.GA38132@bts.sk> On Wed, Sep 22, 2010 at 04:18:59AM -0600, Ross Finlayson wrote: > Yes, and for this reason (especially given the ambiguity in the RTSP > specification), I have now installed a new version (2010.09.22) that > will accept both kinds of "port=" parameter. Great, thanks for the fast resolution! With kind regards, M. From finlayson at live555.com Wed Sep 22 03:49:04 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 22 Sep 2010 04:49:04 -0600 Subject: [Live-devel] live555MediaServer: RTP source address does not match RTSP source address In-Reply-To: <201009221219.32818.david.stegbauer@acision.com> References: <201009221219.32818.david.stegbauer@acision.com> Message-ID: Your solution to this problem seems reasonable. I will likely include it in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ferry at bertin.fr Wed Sep 22 08:17:33 2010 From: ferry at bertin.fr (Guillaume Ferry) Date: Wed, 22 Sep 2010 17:17:33 +0200 Subject: [Live-devel] Asynchronous API - Subclassing troubles In-Reply-To: <4C98B91F.6080205@bertin.fr> References: <4C978BF7.5060705@bertin.fr> <4C98B91F.6080205@bertin.fr> Message-ID: <4C9A1E0D.9030406@bertin.fr> Hi Ross, Ok, it works just fine on your side, I was using an old object reference from my own libraries ! Asynchronous is so great. Regards, Guillaume. Le 21/09/2010 15:54, Guillaume Ferry a ?crit : > Le 20/09/2010 19:44, Ross Finlayson a ?crit : >>> **** BackTrace **** >>> >>> #0 0x080882af in _Tables::getOurTables(UsageEnvironment&, unsigned >>> int) () >> >> The fact that you're seeing a crash in such an innocuous function >> suggests to me that you may be linking with old binaries somewhere. >> (I assume that you're not doing something stupid like trying to >> access the library from multiple threads.) >> >> So, my first suggestion would be to remove all of your binaries, and >> then recompile/relink everything from scratch. > Hi Ross, > > Thanks for assuming this :) > Of course, I'm not using it in a multi-threaded context, right now, it > is just a small sample application, launching one RTSP connection. > I rebuilt all libs from scratch, but it still crashes. > > I'll dive into openRTSP code, because I must have missed something. > I'll keep you in touch very soon. > > Best regards, > Guillaume. > > -- > Guillaume FERRY > Bertin Technologies > D?partement Bertin Conseil > Activit? Traitement de l'Information et du Contenu > /T?l/ 01.39.30.62.09 > /Fax/ 01.39.30.62.45 > /Mail/ ferry at bertin.fr > /Web/ www.bertin.fr > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -- Guillaume FERRY Bertin Technologies D?partement Bertin Conseil Activit? Traitement de l'Information et du Contenu /T?l/ 01.39.30.62.09 /Fax/ 01.39.30.62.45 /Mail/ ferry at bertin.fr /Web/ www.bertin.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From fesparza at itesm.mx Wed Sep 22 08:43:01 2010 From: fesparza at itesm.mx (Francisco Esparza) Date: Wed, 22 Sep 2010 10:43:01 -0500 Subject: [Live-devel] H264 ipcamera problem Message-ID: <1285170181.1494.57.camel@paco-cde> Hello, I'm using openRTSP to capture the video stream from a h264 ip camera, I use openRTSP -t -v -n rtsp://ip_camera:8888 > video I send the video to a pipe and when I play the video with openCV I get the following: non-existing PPS referenced non-existing PPS 0 referenced decode_slice_header error no frame! max_analyze_duration reached Estimating duration from bitrate, this may be inaccurate This error repeats a lot of times, and finnaly I can watch the video for about 5 seconds and then it freezes. I read about this and I think is because there is no header in the NAL units, I saw in h264VideoFileSink file that there is a header 00000001 unsigned char start_code[4] = {0x00, 0x00, 0x00, 0x01}; addData(start_code, 4, presentationTime); Any help will be really appreciated. Thanks, From serge.grondin at gmail.com Wed Sep 22 14:28:47 2010 From: serge.grondin at gmail.com (Serge Grondin) Date: Wed, 22 Sep 2010 17:28:47 -0400 Subject: [Live-devel] H264 ipcamera problem In-Reply-To: <1285170181.1494.57.camel@paco-cde> References: <1285170181.1494.57.camel@paco-cde> Message-ID: Hi Francisco, I had this kind of problem before when talking to some RTSP server. Sometimes the SPS (type 7) and PPS (type 8) NAL units are encoded in base64 and given to client inside the SDP description. When you want to decode such a stream you have to reinsert them before each IDR (type 5) NAL units. Also you need to reinsert the start code 0x00000001 before all NAL units that you receive, otherwise your decoder won't recognize this as a valid h.264 data stream. Good luck! Serge -------------------------------------------------- From: "Francisco Esparza" Sent: Wednesday, September 22, 2010 11:43 To: Subject: [Live-devel] H264 ipcamera problem > Hello, > > I'm using openRTSP to capture the video stream from a > h264 ip camera, I use > > openRTSP -t -v -n rtsp://ip_camera:8888 > video > > I send the video to a pipe and when I play the video with openCV I get > the following: > > non-existing PPS referenced > non-existing PPS 0 referenced > decode_slice_header error > no frame! > > max_analyze_duration reached > Estimating duration from bitrate, this may be inaccurate > > This error repeats a lot of times, and finnaly I can watch the video for > about 5 seconds and then it freezes. I read about this and I think is > because there is no header in the NAL units, I saw in h264VideoFileSink > file that there is a header 00000001 > > unsigned char start_code[4] = {0x00, 0x00, 0x00, 0x01}; > addData(start_code, 4, presentationTime); > > Any help will be really appreciated. > > Thanks, > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From finlayson at live555.com Wed Sep 22 23:46:55 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 23 Sep 2010 00:46:55 -0600 Subject: [Live-devel] Updated "H264VideoFileSink" to take an option "sprop parameter string" argument Message-ID: I have released a new version (2010.09.23) of the "LIVE555 Streaming Media" code that updates the "H264VideoFileSink" class (which "openRTSP" uses when recording a H.264 RTSP/RTP stream) to take an optional "sprop parameter string" argument. If present, this string is decoded, and the resulting data (SPS/PPS NAL units) is prepended to the file. Also, "openRTSP" has been updated to pass the "sprop parameter string" (obtained from the SDP description) when creating a "H2564VideoFileSink". This should overcome a problem that many people have had when using "openRTSP" to record a H.264 RTSP/RTP stream. The SPS and PPS NAL units (if included in the SDP description) will be now prepended to the output file, hopefully making it easier to decode. NOTE: I haven't had a chance to fully debug this new version myself, because I currently don't have access to a H.264 RTSP/RTP stream. Could someone with access to such a stream please test out this new version (with "openRTSP")? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Sep 22 23:48:44 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 23 Sep 2010 00:48:44 -0600 Subject: [Live-devel] H264 ipcamera problem In-Reply-To: References: <1285170181.1494.57.camel@paco-cde> Message-ID: >I had this kind of problem before when talking to some RTSP server. >Sometimes the SPS (type 7) and PPS (type 8) NAL units are encoded in >base64 and given to client inside the SDP description. When you >want to decode such a stream you have to reinsert them before each >IDR (type 5) NAL units. Please download the latest version (2010.09.23) of the LIVE555 Streaming Media code. In this new version, "openRTSP" will automatically prepend these SPS and PPS NAL units to the output file. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From wlm at tid.es Thu Sep 23 01:13:26 2010 From: wlm at tid.es (wlm) Date: Thu, 23 Sep 2010 10:13:26 +0200 Subject: [Live-devel] Launch client whit Ip Address secondary? Message-ID: <4C9B0C26.8070705@tid.es> Dear, How I could launch client whit IP address secondary, of manner that when launch $ ./openRTSP here I can to write the IP address secondary that has the card network configured. Where I can to modify The code? Thanks Best Regards William L?ligo Monsalve Optical Network www.tid.es Spain From sebastien-devel at celeos.eu Thu Sep 23 01:17:57 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Thu, 23 Sep 2010 10:17:57 +0200 Subject: [Live-devel] new API and callbacks In-Reply-To: References: <1285080638.10388.6.camel@sebastien-desktop> Message-ID: <1285229877.11443.4.camel@sebastien-desktop> Hi Ross, Another question about callbacks. Is it ok to pass a NULL callback if we don't care about the response ? It seems to be ok, and it seems to be checked in your code, but as it is not explicitly authorized in your functions descriptions (RTSPClient.hh), I wanted to be sure it is supported. Thanks. From wlm at tid.es Thu Sep 23 01:19:26 2010 From: wlm at tid.es (wlm) Date: Thu, 23 Sep 2010 10:19:26 +0200 Subject: [Live-devel] [Fwd: Launch client whit Ip Address secondary?] Message-ID: <4C9B0D8E.3010002@tid.es> -------------- next part -------------- An embedded message was scrubbed... From: wlm Subject: Launch client whit Ip Address secondary? Date: Thu, 23 Sep 2010 10:13:26 +0200 Size: 840 URL: From finlayson at live555.com Thu Sep 23 03:31:26 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 23 Sep 2010 04:31:26 -0600 Subject: [Live-devel] new API and callbacks In-Reply-To: <1285229877.11443.4.camel@sebastien-desktop> References: <1285080638.10388.6.camel@sebastien-desktop> <1285229877.11443.4.camel@sebastien-desktop> Message-ID: >Another question about callbacks. >Is it ok to pass a NULL callback if we don't care about the response ? >It seems to be ok, and it seems to be checked in your code, but as it is >not explicitly authorized in your functions descriptions >(RTSPClient.hh), I wanted to be sure it is supported. Yes, that's fine. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From david.stegbauer at acision.com Thu Sep 23 05:47:27 2010 From: david.stegbauer at acision.com (David Stegbauer) Date: Thu, 23 Sep 2010 14:47:27 +0200 Subject: [Live-devel] live555MediaServer: RTP source address does not match RTSP source address In-Reply-To: References: <201009221219.32818.david.stegbauer@acision.com> Message-ID: <201009231447.28140.david.stegbauer@acision.com> Hello Ross, On Wednesday 22 September 2010 12:49:04 Ross Finlayson wrote: > Your solution to this problem seems reasonable. I will likely > include it in the next release of the software. I have made more tests (added one more network interface) and the hack with SendingInterfaceAddr and ReceivingInterfaceAddr didn't work as expected. I think I've missed something. I'm in the process of modifying Socket, GroupSock and so on. I'll keep you in loop. Best Regards David Stegbauer This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From finlayson at live555.com Thu Sep 23 08:21:08 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 23 Sep 2010 09:21:08 -0600 Subject: [Live-devel] live555MediaServer: RTP source address does not match RTSP source address In-Reply-To: <201009231447.28140.david.stegbauer@acision.com> References: <201009221219.32818.david.stegbauer@acision.com> <201009231447.28140.david.stegbauer@acision.com> Message-ID: >On Wednesday 22 September 2010 12:49:04 Ross Finlayson wrote: >> Your solution to this problem seems reasonable. I will likely >> include it in the next release of the software. > >I have made more tests (added one more network interface) and the hack with >SendingInterfaceAddr and ReceivingInterfaceAddr didn't work as expected. Arggh! I thought this was going to be OK. I've now installed a new version (2010.09.23a) that undoes this. >I'm in the process of modifying Socket, GroupSock and so on. Sorry, but it's unlikely that I'll be accepting changes to this code (because it's so fundamental to the rest of the system). You're on your own here... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mehran at stretchinc.com Thu Sep 23 15:35:41 2010 From: mehran at stretchinc.com (Mehran Ansari) Date: Thu, 23 Sep 2010 15:35:41 -0700 (PDT) Subject: [Live-devel] Questions on On Demand Live Video Streaming Server In-Reply-To: <498486687.9991285281264274.JavaMail.root@mail.stretchinc.com> Message-ID: <426938852.10011285281341938.JavaMail.root@mail.stretchinc.com> I have been trying to understand live555 by using and reading the test programs but I can not figure out how I can use OnDemandRTSP to stream any type of Live Video. I used "[Live-devel] H264 RTP Streaming: A Tutorial" as a base to stream live H.264, the problem is that even though I see the video frames are being streamed from my server and on my client side running wireshark which sees the frames receiving, VLC does not play the video. Additionally this example does not use On Demand RTSP which I need to know when to start and stop streaming. I need know: 1) Which class to sub-class in order to have On Demand RTSP server which receives RTSP requests for any video CODECs (mpeg4, h.264, MJPEG). 2) be able to know when the RTSP PLAY is received by sub-classing one of the RTPS classes and get the IP address of the client 3) start sending frames which are obtained from any of my video encoders to the client that initiated the PLAY 4) be notified when the RTSP STOP is received and know which client IP Address Most probably the answer is to sub-class OnDemandServerMediaSubsession, ServerMediaSubsession, or something else. If I sub-class any of these Media Subsession servers, would I call the startPlaying() for myVideoSenderSink class from the startStream() virtual method and then feed my video frames through doGetNextFrame() of my video framer class? Is there generic video frame class for any type of Elementary Streaming Video? Is there any example test that is similar to what I am looking for? I appreciate any help and hints as where I should start. From Larry.Cui at zoran.com Thu Sep 23 15:56:54 2010 From: Larry.Cui at zoran.com (Larry Cui) Date: Thu, 23 Sep 2010 22:56:54 +0000 Subject: [Live-devel] RTP over RTSP over HTTP Message-ID: I want to know if live555 supports rtp over rtsp over http or not. But in the live555 2010.9.10, It says in live555MediaServer.cpp: // RTSP-over-HTTP tunneling is not yet working // Also, attempt to create a HTTP server for RTSP-over-HTTP tunneling. // Try first with the default HTTP port (80), and then with the alternative HTTP // port number (8000). Does live555 support rtp over rstp over http right now? Thanks, -Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehran at stretchinc.com Fri Sep 24 09:56:32 2010 From: mehran at stretchinc.com (Mehran Ansari) Date: Fri, 24 Sep 2010 09:56:32 -0700 (PDT) Subject: [Live-devel] openRTP does not save all of the video frames into the file Message-ID: <29681839.2331285347392206.JavaMail.root@mail.stretchinc.com> I am using DynamicRTSPServer to send a M4E (MPEG4 elementary stream) file. Using VLC, I can connect to the server and see my video being played. Now I like to capture the same video frames into a file. I used "openRTP " this creates a file as expected but the content of the file is only 29 bytes. I re-build the openRTP with debugLevel set to 3 in the groupsock class to see what size frames I am receiving. The output is only showing a few lines of receiving 32 or 60 bytes buffer. Is this the correct way to see what size buffers are being received by the openRTP? Do I need to specify any other flag on the command line in addition to the URL in order to save all the video frames? Lastly, does the openRTP care if what video CODEC elementary stream it receives? or does it just save any data received into a file? Thanks for your help. From mehran at stretchinc.com Fri Sep 24 13:56:09 2010 From: mehran at stretchinc.com (Mehran Ansari) Date: Fri, 24 Sep 2010 13:56:09 -0700 (PDT) Subject: [Live-devel] VLC does not display any video when streaming with testMPEG4VideoStreamer In-Reply-To: <1121103306.4801285361750963.JavaMail.root@mail.stretchinc.com> Message-ID: <683925249.4821285361769018.JavaMail.root@mail.stretchinc.com> Using live555MediaServer I can see the content of a .m4e file which is displayed by VLC but when I use testMPEG4VideoStreamer to stream the same file, VLC does not display anything. But it also does not complain nor displays any error messages. I do have test.m4e in the testProg folder, and the testMPEG4VideoStreamer program seems to be sending frames but VLC is not displaying it. I modeled my application after testMPEG4VideoStreamer to send live video frames and I also experience the same problem. What could I be missing? Does this program work for others? I am using live.2010.09.23a source code. Thanks for your help. From finlayson at live555.com Fri Sep 24 18:56:18 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 24 Sep 2010 18:56:18 -0700 Subject: [Live-devel] VLC does not display any video when streaming with testMPEG4VideoStreamer In-Reply-To: <683925249.4821285361769018.JavaMail.root@mail.stretchinc.com> References: <683925249.4821285361769018.JavaMail.root@mail.stretchinc.com> Message-ID: Thanks for the note. I can reproduce the problem with "testMPEG4VideoStreamer"s multicast data not being received by "openRTSP" (and presumably by "VLC"). (However, a unicast MPEG-4 video stream sent by "live555MediaServer" can be received OK by both "openRTSP" and "VLC".) I am investigating. Stay tuned... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Sep 24 19:09:06 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 24 Sep 2010 19:09:06 -0700 Subject: [Live-devel] RTP over RTSP over HTTP In-Reply-To: References: Message-ID: >I want to know if live555 supports rtp over rtsp over http or not. At the client end, yes. At the server end, not yet. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Sep 25 06:21:31 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 25 Sep 2010 06:21:31 -0700 Subject: [Live-devel] VLC does not display any video when streaming with testMPEG4VideoStreamer Message-ID: OK, I've now identified the problem - it was caused by the fact that "testMPEG4VideoStreamer" uses 'source-specific multicast' (SSM), and an optimization that we were using for SSM was apparently causing problems (at least, when the receiving application was running on the same host as the sender). I have now installed a new version (2010.09.25) of the code that should overcome this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ritalinfortheboy at gmail.com Sun Sep 26 19:09:18 2010 From: ritalinfortheboy at gmail.com (Rob) Date: Sun, 26 Sep 2010 22:09:18 -0400 Subject: [Live-devel] Live on iPhone In-Reply-To: References: Message-ID: Hi, I was wondering if anyone can provide a sample implementing Live on iPhone? Thanks and regards, Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From Abhishek.Jain at honeywell.com Mon Sep 27 23:46:04 2010 From: Abhishek.Jain at honeywell.com (Jain, Abhishek) Date: Tue, 28 Sep 2010 12:16:04 +0530 Subject: [Live-devel] RTSP client takes significant time to close. Message-ID: Hi Ross, When RTSP server does not send video strea, the following line at RTSP client takes more time (sometimes in the order of seconds) to return int selectResult = select(fMaxNumSockets, &readSet, NULL, NULL, &tv_timeToDelay); When client application closes the RTSP client, how to ensure that the above line to return immediately (e.g. within 500 milliseconds max.)? Regards Abhishek Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 28 01:11:06 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 28 Sep 2010 01:11:06 -0700 Subject: [Live-devel] RTSP client takes significant time to close. In-Reply-To: References: Message-ID: >When RTSP server does not send video strea, the following line at >RTSP client takes more time (sometimes in the order of seconds) to >return >int selectResult = select(fMaxNumSockets, &readSet, NULL, NULL, >&tv_timeToDelay); > >When client application closes the RTSP client, how to ensure that >the above line to return immediately (e.g. within 500 milliseconds >max.)? You will need to arrange for an event to happen - within that time frame - that will be recognized by the event loop. The simplest way to do this is to create a periodic task. For an illustration, see -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehran at stretchinc.com Wed Sep 29 08:35:43 2010 From: mehran at stretchinc.com (Mehran Ansari) Date: Wed, 29 Sep 2010 08:35:43 -0700 (PDT) Subject: [Live-devel] VLC does not display any video when streaming with testMPEG4VideoStreamer In-Reply-To: <640662412.631285774367359.JavaMail.root@mail.stretchinc.com> Message-ID: <402121524.651285774543199.JavaMail.root@mail.stretchinc.com> Thanks for the response. I got latest version (2010.09.25) and built server testMPEG4VideoStreamer in Linux and the openRTSP in both Linux and Windows. After executing testMPEG4VideoStreamer.exe in Linux I still could not see any video from VLC in Windows. I then ran openRTSP from Windows. The program crashed in GroupScokHelper.cpp line 635 due to the fact that ctime() returned NULL. I then commented out processing of string time which causes the time string to be NULL and ran opeRTSP in windows. Now, the program does not crash but I still get a file with only 29 bytes in it. Then I realized the problem maybe with the firewall in Windows. After I added openRTSP and VLC to the exception tab of Windows Firewall. I was able to receive video frames by openRTSP but VLC only shows one frame and then stops. My question is that: 1) why does ctime() usage in openRTSP.exe in Windows returns NULL which causes the crash? I see that openRTSP has its own implementation of getting time of the day. 2) Is there any way to stream behind the Firewall? 3) Is there any trick in VLC that would allow me to see video streams? NOTE: Now openRTSP receives and saves all of the video frames streamed. From finlayson at live555.com Wed Sep 29 15:22:24 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 Sep 2010 15:22:24 -0700 Subject: [Live-devel] VLC does not display any video when streaming with testMPEG4VideoStreamer In-Reply-To: <402121524.651285774543199.JavaMail.root@mail.stretchinc.com> References: <402121524.651285774543199.JavaMail.root@mail.stretchinc.com> Message-ID: >Thanks for the response. I got latest version (2010.09.25) and built >server testMPEG4VideoStreamer in Linux and the openRTSP in both >Linux and Windows. > >After executing testMPEG4VideoStreamer.exe in Linux I still could >not see any video from VLC in Windows. I then ran openRTSP from >Windows. That's strange. I successfully tested testMPEG4VideoStreamer and VLC (version 1.1.3) on Mac OS X (with both running on the same machine, though it would also have worked over a (multicast-capable) network). In any case, VLC is not our software, so if you see any problems with VLC - but not with "openRTSP" (our own RTSP/RTP client) running on the *same* computer - then you should report it to a VLC mailing list instead. > The program crashed in GroupScokHelper.cpp line 635 due to the fact >that ctime() returned NULL This is the problem that you should address first. I have never heard of anyone else encountering this problem before, so I suspect that you may have a problem with some binaries being out of date. I suggest removing *all* LIVE555 binary files, and compiling linking everything from scratch. In any case, I suggest doing your testing with Linux first (i.e., with "testMPEG4VideoStreamer" and "openRTSP"), as Linux software is easier to build then Windows. In particular, I suggest testing in the following order: 1/ "testMPEG4VideoStreamer" running on a Linux computer; "openRTSP" running on the same Linux computer. 2/ "testMPEG4VideoStreamer" running on a Linux computer; "openRTSP" running on a different Linux computer (but on the same multicast-connected network). 3/ "testMPEG4VideoStreamer" running on a Linux computer; "openRTSP" running on a Windows computer (on the same multicast-connected network). 4/ "testMPEG4VideoStreamer" running on a Linux computer; "VLC" running on a Windows computer (on the same multicast-connected network). If 1/ through 3/ work OK, but not 4/, then you have a problem with VLC (and thus not a problem for this mailing list). However, in this case I would also test VLC running on a Mac OS X computer, as that works OK for me. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From atg at Cs.Nott.AC.UK Thu Sep 30 06:54:32 2010 From: atg at Cs.Nott.AC.UK (Tony Glover) Date: Thu, 30 Sep 2010 14:54:32 +0100 Subject: [Live-devel] VLC does not display any video when streaming with testMPEG4VideoStreamer In-Reply-To: References: <402121524.651285774543199.JavaMail.root@mail.stretchinc.com> Message-ID: <4CA49698.8090305@cs.nott.ac.uk> Ross Finlayson wrote: >> The program crashed in GroupScokHelper.cpp line 635 due to the fact >> that ctime() returned NULL > > This is the problem that you should address first. I have never heard > of anyone else encountering this problem before, so I suspect that you > may have a problem with some binaries being out of date. I suggest > removing *all* LIVE555 binary files, and compiling linking everything > from scratch. Hi, I have seen this error before on windows, but I didn't delve into it particularly deeply. It relates to the timestamp value being greater than the windows-defined maximum time value (something like _MAX__TIME64_T if I remember correctly). It only occurs when called from live's timestamping function which is itself only called when outputting debugging information as far as I know. You can either stop outputting any debug info until you know what the real issue is or just check for a null value returned from ctime(). Cheers, Tony.