From ruru605 at 163.com Sun Apr 1 19:54:33 2007 From: ruru605 at 163.com (ruru605) Date: Mon, 2 Apr 2007 11:54:33 +0900 Subject: [Live-devel] question about client's buffer Message-ID: <200704021154319530560@163.com> Hi, everyone I have a question about buffer of client. 1. Is there a max limit to the client's buffer? 2. After receving a packet into the client's buffer, will it send it to player to play directly or wait for a threshold number? I read some codes and I did not find the max limit and send it directly. However, I am not quite sure and I'm not sure this is good or not. Please help me know the exact answer. Thanks very much. ruru605 2007-04-02 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070401/752cc866/attachment.html From sripadnavali at yahoo.co.in Sun Apr 1 22:53:48 2007 From: sripadnavali at yahoo.co.in (sripad _n) Date: Mon, 2 Apr 2007 06:53:48 +0100 (BST) Subject: [Live-devel] About The file system of server after building live555 code Message-ID: <979492.11350.qm@web7908.mail.in.yahoo.com> Hi, I have built media server code and wnat to know whether Root and other directories are created by itself or they has to be created by us where the files to be streamed are to be stored. --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070401/a16d6136/attachment.html From miroslaw.dach at psi.ch Mon Apr 2 03:06:32 2007 From: miroslaw.dach at psi.ch (Miroslaw Dach) Date: Mon, 2 Apr 2007 12:06:32 +0200 (CEST) Subject: [Live-devel] firewire camera and Media server Message-ID: Hi All, I have installed live package and compiled it. It looks great and it is almost that what I was looking for. I am just interested in converting a live video from firewire camera (raw data) to a video stream. This what I see that the LIVE555 Media Server operates on the videos stored in the data files. Would it be also possible to use it in conjunction with the firewire camera. Best Regards Mirek ============================================================================= Miroslaw Dach (Miroslaw.Dach at psi.ch) - SLS/Controls Group PSI - Paul Scherrer Institut CH-5232 Villigen ============================================================================= From julian.lamberty at mytum.de Mon Apr 2 06:38:21 2007 From: julian.lamberty at mytum.de (Julian Lamberty) Date: Mon, 02 Apr 2007 15:38:21 +0200 Subject: [Live-devel] Integrate ffmpeg transcoder into Live555 Message-ID: <4611074D.6090806@mytum.de> Hi! I'm trying to transcode network streams (RTP/RTSP) "on the fly" with the libavcodec libraries. Right now I've just a small application that opens a file as an input an writes to a file. I'm now planning to use the live555 framework and integrate my transcoder into it (feed ffmpeg with frames from live555 and stream the ffmpeg output frames with live555). Is there anyone who has done something similar before and has some example code? I'm just a newbie (especially to C++), so that seems like a lot of work for me ;) Thanks for any kind of help! Julian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5198 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.live555.com/pipermail/live-devel/attachments/20070402/ae30151e/attachment.bin From finlayson at live555.com Mon Apr 2 07:18:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 2 Apr 2007 07:18:43 -0700 Subject: [Live-devel] firewire camera and Media server In-Reply-To: References: Message-ID: >I am just interested in converting a live video from firewire camera (raw >data) to a video stream. This what I see that the LIVE555 Media Server >operates on the videos stored in the data files. Would it be also possible >to use it in conjunction with the firewire camera. What format is the data coming from the 'firewire camera'? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Apr 2 07:19:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 2 Apr 2007 07:19:23 -0700 Subject: [Live-devel] Integrate ffmpeg transcoder into Live555 In-Reply-To: <4611074D.6090806@mytum.de> References: <4611074D.6090806@mytum.de> Message-ID: >I'm now planning to use the live555 framework and integrate my >transcoder into it (feed ffmpeg with frames from live555 and stream >the ffmpeg output frames with live555). Is there anyone who has done >something similar before and has some example code? I'm just a >newbie (especially to C++), so that seems like a lot of work for me >;) Please read the FAQ. It has some entries related to this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From miroslaw.dach at psi.ch Tue Apr 3 00:05:39 2007 From: miroslaw.dach at psi.ch (Miroslaw Dach) Date: Tue, 3 Apr 2007 09:05:39 +0200 (CEST) Subject: [Live-devel] firewire camera and Media server In-Reply-To: Message-ID: The data format for firewire is completely raw RGB 3x8bit or gray 8 or 16bit per pixel or Bayer pattern RGB. Camera sends each time entire images. Best Regards Mirek On Mon, 2 Apr 2007, Ross Finlayson wrote: > >I am just interested in converting a live video from firewire camera (raw > >data) to a video stream. This what I see that the LIVE555 Media Server > >operates on the videos stored in the data files. Would it be also possible > >to use it in conjunction with the firewire camera. > > What format is the data coming from the 'firewire camera'? > -- ============================================================================= Miroslaw Dach (Miroslaw.Dach at psi.ch) - SLS/Controls Group PSI - Paul Scherrer Institut CH-5232 Villigen ============================================================================= From finlayson at live555.com Tue Apr 3 00:42:49 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Apr 2007 00:42:49 -0700 Subject: [Live-devel] firewire camera and Media server In-Reply-To: References: Message-ID: >The data format for firewire is completely raw RGB 3x8bit or gray 8 or >16bit per pixel or Bayer pattern RGB. Then you would need to compress this video with a (hardware or software) encoder, before it could be streamed by our server software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From miroslaw.dach at psi.ch Tue Apr 3 01:27:19 2007 From: miroslaw.dach at psi.ch (Miroslaw Dach) Date: Tue, 3 Apr 2007 10:27:19 +0200 (CEST) Subject: [Live-devel] firewire camera and Media server In-Reply-To: Message-ID: > >The data format for firewire is completely raw RGB 3x8bit or gray 8 or > >16bit per pixel or Bayer pattern RGB. > > Then you would need to compress this video with a (hardware or > software) encoder, before it could be streamed by our server software. My aim is to produce a video stream (run time) in let say MPEG4 (part 10) out of the video which comes from my firewire camera. Such a stream is not meant to be saved in a file but be ready for viewing over internet. My firewire camera is attached to the Linux PC. Would you recommend me some software to achieve that. Best Regards Mirek ============================================================================= Miroslaw Dach (Miroslaw.Dach at psi.ch) - SLS/Controls Group PSI - Paul Scherrer Institut CH-5232 Villigen ============================================================================= From pcg at agathongroup.com Tue Apr 3 16:19:34 2007 From: pcg at agathongroup.com (peter green) Date: Tue, 3 Apr 2007 17:19:34 -0600 Subject: [Live-devel] openrtsp, ffmpeg, and poor H.261 video Message-ID: <20070403231934.GA29131@agathongroup.com> I'm pulling from a Darwin Streaming Server that is broadcasting an SDP from a Polycom VSX7000e video teleconferencing thing. I've been able to use openrtsp to dump the H261 packets along with ulaw packets to individual files. I've been able to reassemble them with ffmpeg. However, the video is terribly pixelated whenever there is movement on camera. The stream I'm pulling looks fine in QuickTime, but the same Quicktime shows really poor quality video when I reassemble it into a .mov. My command lines: $ openRTSP -u user pass -e 30 rtsp://10.9.0.1/videostream.sdp $ ffmpeg -y -r 15 -ar 8000 -acodec pcm_mulaw -f mulaw -i audio-PCMU-2 -f h261 -i video-H261-1 output.mov On the original stream, QuickTime shows: Format: H.261, 352x288, Millions+ u-Law 2:1, Mono, 8.000 kHz FPS: 0 Playing FPS: 15 I'm going to check with the ffmpeg list because I have no idea where the problem is occurring. All I know is that the stream shows fine in Quicktime and is garbage once it passes through openRTSP and ffmpeg. I'm at my wit's end; does anyone know where I should look? Thanks! /pg -- Peter Green : Agathon Group : pcg at agathongroup.com From julian.lamberty at mytum.de Wed Apr 4 00:56:17 2007 From: julian.lamberty at mytum.de (Julian Lamberty) Date: Wed, 04 Apr 2007 09:56:17 +0200 Subject: [Live-devel] Integrate ffmpeg transcoder into Live555 Message-ID: <46135A21.4010309@mytum.de> >>I'm now planning to use the live555 framework and integrate my >>transcoder into it (feed ffmpeg with frames from live555 and stream >>the ffmpeg output frames with live555). Is there anyone who has done >>something similar before and has some example code? I'm just a >>newbie (especially to C++), so that seems like a lot of work for me >> ;) >Please read the FAQ. It has some entries related to this. Well, I've already done that. But does anyone know where to find a more detailed example? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5198 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.live555.com/pipermail/live-devel/attachments/20070404/758d5bd6/attachment.bin From lucabe72 at email.it Wed Apr 4 06:13:47 2007 From: lucabe72 at email.it (Luca Abeni) Date: Wed, 04 Apr 2007 15:13:47 +0200 Subject: [Live-devel] Question about "packetIsUsableInJitterCalculation()" Message-ID: <4613A48B.4000302@email.it> Hi all, I see that the definition of the packetIsUsableInJitterCalculation() method in MPEG1or2VideoRTPSource only allows to use a frame for computing the jitter if it is an I frame. Is this to avoid bitstream-ordering problems if B frames are used? (I mean, if I know that my stream has no B frames, is it safe to always return True?) Thanks, Luca From lucabe72 at email.it Wed Apr 4 07:52:00 2007 From: lucabe72 at email.it (Luca Abeni) Date: Wed, 04 Apr 2007 16:52:00 +0200 Subject: [Live-devel] How to read RR statistics? Message-ID: <4613BB90.60403@email.it> Hi all, when using a class derived from RTSPServer (or from DynamicRTSPServer), how can I be notified when an RTCP Receiver Report packet arrives, and how can I read the jitter and lost packets number from it? I see the information I need are stored in an object of class RTPTransmissionStats, which is associated to an RTPSink, which (if I understand well) is dynamically created when the RTSP server receives a PLAY command. Now, how can I access this RTPSink (ideally, I'd like to set the RRHandlerTask for the RTCP session, and pass a pointer to the RTPSink as a parameter to the handler)? I am browsing the RTSPServer code, but it seems to me that all the information I need are private... Or am I approaching the problem in the wrong way? Thanks, Luca From finlayson at live555.com Wed Apr 4 15:14:24 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 4 Apr 2007 15:14:24 -0700 Subject: [Live-devel] How to read RR statistics? In-Reply-To: <4613BB90.60403@email.it> References: <4613BB90.60403@email.it> Message-ID: >when using a class derived from RTSPServer (or from DynamicRTSPServer), >how can I be notified when an RTCP Receiver Report packet arrives, and >how can I read the jitter and lost packets number from it? > >I see the information I need are stored in an object of class >RTPTransmissionStats, which is associated to an RTPSink, which (if I >understand well) is dynamically created when the RTSP server receives a >PLAY command. Now, how can I access this RTPSink (ideally, I'd like to >set the RRHandlerTask for the RTCP session, and pass a pointer to the >RTPSink as a parameter to the handler)? You can access the "RTPSink" object in your "ServerMediaSubsession" subclass (in its implementation of the "createNewRTPSink()" virtual function). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Apr 4 16:05:35 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 4 Apr 2007 16:05:35 -0700 Subject: [Live-devel] Question about "packetIsUsableInJitterCalculation()" In-Reply-To: <4613A48B.4000302@email.it> References: <4613A48B.4000302@email.it> Message-ID: >Hi all, > >I see that the definition of the packetIsUsableInJitterCalculation() >method in MPEG1or2VideoRTPSource only allows to use a frame for >computing the jitter if it is an I frame. >Is this to avoid bitstream-ordering problems if B frames are used? >(I mean, if I know that my stream has no B frames, is it safe to always >return True?) Yes, probably. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From lucabe72 at email.it Thu Apr 5 01:08:54 2007 From: lucabe72 at email.it (Luca Abeni) Date: Thu, 05 Apr 2007 10:08:54 +0200 Subject: [Live-devel] How to read RR statistics? In-Reply-To: References: <4613BB90.60403@email.it> Message-ID: <4614AE96.1010304@email.it> Hi Ross, thanks for the answer. Ross Finlayson wrote: [...] >> I see the information I need are stored in an object of class >> RTPTransmissionStats, which is associated to an RTPSink, which (if I >> understand well) is dynamically created when the RTSP server receives a >> PLAY command. Now, how can I access this RTPSink (ideally, I'd like to >> set the RRHandlerTask for the RTCP session, and pass a pointer to the >> RTPSink as a parameter to the handler)? > > You can access the "RTPSink" object in your "ServerMediaSubsession" > subclass (in its implementation of the "createNewRTPSink()" virtual > function). So, just to check if I understand well, for accessing the transmission stats I will have to create a new "ServerMediaSubsession" subclass? Thanks, Luca From finlayson at live555.com Thu Apr 5 01:11:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Apr 2007 01:11:45 -0700 Subject: [Live-devel] How to read RR statistics? In-Reply-To: <4614AE96.1010304@email.it> References: <4613BB90.60403@email.it> <4614AE96.1010304@email.it> Message-ID: >Hi Ross, > >thanks for the answer. > >Ross Finlayson wrote: >[...] >>> I see the information I need are stored in an object of class >>> RTPTransmissionStats, which is associated to an RTPSink, which (if I >>> understand well) is dynamically created when the RTSP server receives a >>> PLAY command. Now, how can I access this RTPSink (ideally, I'd like to >>> set the RRHandlerTask for the RTCP session, and pass a pointer to the >>> RTPSink as a parameter to the handler)? >> >> You can access the "RTPSink" object in your "ServerMediaSubsession" >> subclass (in its implementation of the "createNewRTPSink()" virtual >> function). >So, just to check if I understand well, for accessing the transmission >stats I will have to create a new "ServerMediaSubsession" subclass? Yes - that's where you create (and thus can get access to) your "RTPSink" object. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vahaha at pisem.net Sat Apr 7 04:25:33 2007 From: vahaha at pisem.net (Till May) Date: Sat, 07 Apr 2007 15:25:33 +0400 Subject: [Live-devel] Streaming Live Video. But only for a few sec. Message-ID: <20070407152533.igpx2qu54cg4o8k8@www.pochta.ru> Howdy List !!! I'm a student and doing my degree thesis. I have a little problem on streaming live video. I'm using the last version of LiveMedia. And currently I can stream live video and recieve & play with VLC. But only for a few seconds. After recieving and playing on VLC for a few seconds VLC stops playback, and in statistic of VLC I can see that VLC start to lost frames. At least VLC staying online. As a model I used testMPEG4VideoStreamer. My OS is Win2000 SP4, Devstud is VC++2005. LiveMedia libs are also built under VC++2005 succesfully, after some tricks. I have a GUI, so livemedia loop has a own thread, and I can stop it using watchVarible in any time user want. So in debugging I see that in first call of doGetNextFrame the fMaxSize=150000. But in second call the fMaxSize less then 150000. In third call fMaxSize less then it was in second call. And so on.., As I figured out, always (curent)fMaxSize=(prev)fMaxSize - (prev)fFrameSize. For video of 320x280 resolution size of raw frame is 320*280*4=358400 bytes. But encoded frame size is between 7000 and 15000 bytes. So in each call of doGetNextFrame I check usb Webcam for a responce and grab current frame. Then call deliverFrame where grabed frame encoded by encoder, and delivered to fTO, set fFrameSize to encoded frame size. In each calls fMaxSize becomes less then in prev call. So, in the end after delivering 13~16 frames fMaxSize becomes less than encoded frame size. And deliverFrame starts to trancate encoded frame, and sets fNumTrancatedBytes. It's happen once. And in next call fMaxSize again becomes equal around of 150000, not bigger. And loop starts again... But for a while. And programm crashes, more precisly for some reason afterPlaying func is called... Here doGetNextFrame and dilverFrame codes. Your suggestions are greatly appreciated. Thank you. void WebCamDeviceSource::doGetNextFrame() { // Arrange here for our "deliverFrame" member function to be called // when the next frame of data becomes available from the device. // This must be done in a non-blocking fashion - i.e., so that we // return immediately from this function even if no data is // currently available. // // If the device can be implemented as a readable socket, then one easy // way to do this is using a call to // envir().taskScheduler().turnOnBackgroundReadHandling( ... ) // (See examples of this call in the "liveMedia" directory.) // If, for some reason, the source device stops being readable // (e.g., it gets closed), then you do the following: if (NULL == m_NCvideo.GrabCurrentFrame() /* the source stops being readable */) { handleClosure(this); ::MessageBoxA(NULL,"In Grab Image V4l, the source stops being readable !!!!","Error",MB_OK); return; } deliverFrame(); } void WebCamDeviceSource::deliverFrame() { // This would be called when new frame data is available from the device. // This function should deliver the next frame of data from the device, // using the following parameters (class members): // 'in' parameters (these should *not* be modified by this function): // fTo: The frame data is copied to this address. // (Note that the variable "fTo" is *not* modified. Instead, // the frame data is copied to the address pointed to by "fTo".) // fMaxSize: This is the maximum number of bytes that can be copied // (If the actual frame is larger than this, then it should // be truncated, and "fNumTruncatedBytes" set accordingly.) // 'out' parameters (these are modified by this function): // fFrameSize: Should be set to the delivered frame size (<= fMaxSize). // fNumTruncatedBytes: Should be set iff the delivered frame would have been // bigger than "fMaxSize", in which case it's set to the number of bytes // that have been omitted. // fPresentationTime: Should be set to the frame's presentation time // (seconds, microseconds). // fDurationInMicroseconds: Should be set to the frame's duration, if known. if (!isCurrentlyAwaitingData()){ return; // we're not ready for the data yet } // Deliver the data here: // Draw and encode each frame. SIZE s=m_NCvideo.GetResolution(); m_Revelframe.width = (int)s.cx; m_Revelframe.height = (int)s.cy; m_Revelframe.bytesPerPixel = 4; m_Revelframe.pixelFormat = REVEL_PF_RGBA; m_Revelframe.pixels = new int[m_Revelframe.width*m_Revelframe.height*4]; memset(m_Revelframe.pixels, 0, m_Revelframe.width*m_Revelframe.height*4); if(m_NCvideo.GetBufferUsed() > (long)m_Revelframe.width*m_Revelframe.height*4) { ::MessageBoxA(NULL,"m_NCvideo.GetBufferUsed() > (long)m_Revelframe.width*m_Revelframe.height*4","Internel error",MB_OK); exit(1); } ::memcpy(m_Revelframe.pixels,m_NCvideo.GetBufferPointer(),m_NCvideo.GetBufferUsed()); int frameSize=0; m_RevelError = Revel_EncodeFrame(m_RevelEncoderHandle, &m_Revelframe, &frameSize); if (m_RevelError != REVEL_ERR_NONE) { ::MessageBoxA(NULL,"Revel Error while encode frame: ", "Error",MB_OK); exit(1); } if((fMaxSize) < frameSize) { //"fMaxSize < framSize so trancate it !!! //exit(1); ::memcpy(fTo, m_Revelframe.pixels,fMaxSize); fNumTruncatedBytes=frameSize-fMaxSize; fFrameSize=fMaxSize; } else { ::memcpy(fTo, m_Revelframe.pixels,frameSize); fFrameSize=frameSize; } delete [] (int*)m_Revelframe.pixels; // After delivering the data, switch to another task, and inform // the reader that he has data: // ::MessageBoxA(NULL,"DeliverFrame: successly delivered!!!!"," !!!!!!!!!!!",MB_OK); FramedSource::afterGetting(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070407/e9b08ebb/attachment-0001.html From vahaha at pisem.net Sat Apr 7 05:07:33 2007 From: vahaha at pisem.net (Till May) Date: Sat, 07 Apr 2007 16:07:33 +0400 Subject: [Live-devel] To be more precisly about "Streaming Live Video. But only for a few sec. " Message-ID: <20070407160733.cyg5j7lwn48s8c4c@www.pochta.ru> As encoder in my project encods one frame at a time, and so I can deliver one frame at a time at first I use MPEG1or2VideoStreamDiscreteFramer to feed MPEG4ESVideoRTPSink. But its not work. When I try to use MPEG4VideoStreamFramer and it works fine, but as you know only for few seconds. Is it would be a reason ? thanx. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070407/e7f60fdd/attachment.html From finlayson at live555.com Sat Apr 7 07:21:36 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 7 Apr 2007 07:21:36 -0700 Subject: [Live-devel] To be more precisly about "Streaming Live Video. But only for a few sec. " In-Reply-To: <20070407160733.cyg5j7lwn48s8c4c@www.pochta.ru> References: <20070407160733.cyg5j7lwn48s8c4c@www.pochta.ru> Message-ID: >As encoder in my project encods one frame at a time, and so I can >deliver one frame at a time at first I use >MPEG1or2VideoStreamDiscreteFramer to feed MPEG4ESVideoRTPSink. No, that will never work. Try using "MPEG4VideoStreamDiscreteFramer" to feed "MPEG4ESVideoRTPSink". > When I try to use MPEG4VideoStreamFramer and it works fine, but as >you know only for few seconds. Is it would be a reason ? I don't know. However, I suggest capturing encoded MPEG-4 video data - from your web cam - into a file, named "test.m4v", and then try streaming it using "testMPEG4VideoStreamer" or "testOnDemandRTSPServer". If your data is correct, then you should be able to view/play the stream using VLC as a client. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070407/54336fcc/attachment.html From vlad at crystalballinc.com Sun Apr 8 12:28:12 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Sun, 08 Apr 2007 15:28:12 -0400 Subject: [Live-devel] Possible memory leak Message-ID: <4619424C.6070306@crystalballinc.com> Hi, In RTSPServer in case when index file is used indexFileName gets dynamically allocated but i do not see it is being freed on session close. Thanks -- Vlad Seryakov vlad at crystalballinc.com http://www.crystalballinc.com/vlad/ From finlayson at live555.com Sun Apr 8 16:12:19 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 8 Apr 2007 16:12:19 -0700 Subject: [Live-devel] Possible memory leak In-Reply-To: <4619424C.6070306@crystalballinc.com> References: <4619424C.6070306@crystalballinc.com> Message-ID: >In RTSPServer in case when index file is used indexFileName gets >dynamically allocated but i do not see it is being freed on session close. The index file name is dynamically allocated in the "MPEG2TransportStreamIndexFile" constructor, and deallocated in the destuctor. Also, the "MPEG2TransportStreamIndexFile" object (which contains the allocated index file name string) is created in the "MPEG2TransportFileServerMediaSubsession" constructor, and deallocated in the destructor. So I don't think there's any memory leak there. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vlad at crystalballinc.com Sun Apr 8 16:42:18 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Sun, 08 Apr 2007 19:42:18 -0400 Subject: [Live-devel] Possible memory leak In-Reply-To: References: <4619424C.6070306@crystalballinc.com> Message-ID: <46197DDA.8070205@crystalballinc.com> I did not post correct info, it is allocated in createNewSMS in DynamicRTSPServer.cpp, so for every new session it will be allocated but not freed. Ross Finlayson wrote: >> In RTSPServer in case when index file is used indexFileName gets >> dynamically allocated but i do not see it is being freed on session close. > > The index file name is dynamically allocated in the > "MPEG2TransportStreamIndexFile" constructor, and deallocated in the > destuctor. Also, the "MPEG2TransportStreamIndexFile" object (which > contains the allocated index file name string) is created in the > "MPEG2TransportFileServerMediaSubsession" constructor, and > deallocated in the destructor. So I don't think there's any memory > leak there. -- Vlad Seryakov vlad at crystalballinc.com http://www.crystalballinc.com/vlad/ From finlayson at live555.com Sun Apr 8 16:56:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 8 Apr 2007 16:56:31 -0700 Subject: [Live-devel] Possible memory leak In-Reply-To: <46197DDA.8070205@crystalballinc.com> References: <4619424C.6070306@crystalballinc.com> <46197DDA.8070205@crystalballinc.com> Message-ID: >I did not post correct info, it is allocated in createNewSMS in >DynamicRTSPServer.cpp, so for every new session it will be allocated but >not freed. You're correct - thanks for pointing this out. This will get fixed in the next release of the "LIVE555 Media Server" software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vlad at crystalballinc.com Sun Apr 8 20:59:58 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Sun, 08 Apr 2007 23:59:58 -0400 Subject: [Live-devel] RTSP server extending Message-ID: <4619BA3E.9000704@crystalballinc.com> Hi, Was it intentional that RTSPServer class is impossible to extend because everything is private? I have to to copy it and re-create because i need different access control and socket manipulations, it would be much easier just to extend Authenicator and incomingConnectionHandler1 than maintaining my own copy and keeping with mainstream bugfixes or features. Thank you -- Vlad Seryakov vlad at crystalballinc.com http://www.crystalballinc.com/vlad/ From finlayson at live555.com Sun Apr 8 22:08:29 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 8 Apr 2007 22:08:29 -0700 Subject: [Live-devel] RTSP server extending In-Reply-To: <4619BA3E.9000704@crystalballinc.com> References: <4619BA3E.9000704@crystalballinc.com> Message-ID: >Was it intentional that RTSPServer class is impossible to extend because >everything is private? No, the intention was to allow people to extend this class - although not indiscriminately. If there are specific fields and/or member functions that you feel should be "protected:" instead of "private:", and specific member functions that you feel should be "virtual", let us know, and we'll likely make these changes in the next release of the software. > >I have to to copy it and re-create because i need different access >control and socket manipulations, it would be much easier just to extend >Authenicator and incomingConnectionHandler1 Please let me know what specific changes you would like to see made in order to make this possible. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vahaha at pisem.net Mon Apr 9 07:02:23 2007 From: vahaha at pisem.net (Till May) Date: Mon, 09 Apr 2007 18:02:23 +0400 Subject: [Live-devel] Calling doGetNextFrame Message-ID: <20070409180223.gtai9a8nlwcgg8ow@www.pochta.ru> Hi list. Hi Rossy ! How can I control the calls of doGetNextFrame ?. To be more specific I want to stream live video with 20 fps. As in my doGetNextFrame I'm dilevering one frame at a time so I want doGetNextFrame to be called 20 times per second. Is this possible ? Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070409/edada298/attachment.html From vlad at crystalballinc.com Mon Apr 9 08:59:33 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Mon, 09 Apr 2007 11:59:33 -0400 Subject: [Live-devel] RTSP server extending In-Reply-To: References: <4619BA3E.9000704@crystalballinc.com> Message-ID: <461A62E5.8040900@crystalballinc.com> - As a minimum would be nice to be able to redefine: void incomingConnectionHandler1(); or create another virtual function which is called inside incomingConnectionHandler1 with new accepted socket, so if i need to check network access so i can call getpeername on the new accepted socket - Have access to int fServerSocket; Port fServerPort; - Ability to re-define Authenticator, may be move authentication to the RTSPServer Ross Finlayson wrote: >> Was it intentional that RTSPServer class is impossible to extend because >> everything is private? > > No, the intention was to allow people to extend this class - although > not indiscriminately. If there are specific fields and/or member > functions that you feel should be "protected:" instead of "private:", > and specific member functions that you feel should be "virtual", let > us know, and we'll likely make these changes in the next release of > the software. > >> I have to to copy it and re-create because i need different access >> control and socket manipulations, it would be much easier just to extend >> Authenicator and incomingConnectionHandler1 > > Please let me know what specific changes you would like to see made > in order to make this possible. From jlfurlong at hotmail.com Mon Apr 9 09:39:56 2007 From: jlfurlong at hotmail.com (Jeff Furlong) Date: Mon, 9 Apr 2007 13:39:56 -0300 Subject: [Live-devel] HD MPEG2 TrickPlay Message-ID: Is there a way that the MPEG2 TrickPlay stream that is generated can be generated in a way so that it will be streamed at the same bitrate as in normal playback mode? The reason being is that we're testing with HD MPEG2 video streams (~20 Mbs) on a Moto/Sigma STB. The stream is being delivered over UDP. Playing back in normal mode is fine; however, once trickplay is initiated the STB is unable to handle the higher bitstream. I've tested this with a Kasenna VOD server with the same file and the STB plays the trickplay stream back correctly. When I sniffed the network I noticed that their TrickPlay stream is being sent at the same bitrate as the normal play stream. I did modify the delivery time of the trickplay stream (packets) to be sent at the same rate as the normal playback - however, in this case I just got a black screen, which I'm assuming it had something to do with the timestamps. Does anyone have any thoughts/ideas on the best approach that I could achieve this? Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070409/266ceb39/attachment.html From finlayson at live555.com Mon Apr 9 10:21:03 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2007 10:21:03 -0700 Subject: [Live-devel] Calling doGetNextFrame In-Reply-To: <20070409180223.gtai9a8nlwcgg8ow@www.pochta.ru> References: <20070409180223.gtai9a8nlwcgg8ow@www.pochta.ru> Message-ID: >How can I control the calls of doGetNextFrame ?. To be more specific >I want to stream live video with 20 fps. As in my doGetNextFrame I'm >dilevering one frame at a time so I want doGetNextFrame to be called >20 times per second. >Is this possible ? Yes - this is exactly the purpose of the "fDurationInMicroseconds" member variable. If you set this to 50000 - before calling "FramedSource::afterGetting()", then "doGetNextFrame()" will be called (from "MultiFramedRTPSink") 50 ms apart. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vlad at crystalballinc.com Mon Apr 9 10:33:25 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Mon, 09 Apr 2007 13:33:25 -0400 Subject: [Live-devel] Undereferenced sessions Message-ID: <461A78E5.6000901@crystalballinc.com> Hi, In ServerMediaSession, fDeleteWhenUnreferenced is always False and there is no way to set it True. This means that in RTSPServer::RTSPClientSession::~RTSPClientSession() if (fOurServerMediaSession->referenceCount() == 0 && fOurServerMediaSession->deleteWhenUnreferenced()) is awlays false and current session is never freed, or i miss something. I extend ServerMediaSession class with my own and log new and delete and i see new allocations but never see destructor is being called. From finlayson at live555.com Mon Apr 9 10:43:33 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2007 10:43:33 -0700 Subject: [Live-devel] HD MPEG2 TrickPlay In-Reply-To: References: Message-ID: >Is there a way that the MPEG2 TrickPlay stream that is generated can >be generated in a way so that it will be streamed at the same >bitrate as in normal playback mode? Note that - in the current implementation - the *average* bit rate of 'trick play' streams is actually a bit *less* than that of normal playback mode, because 'trick play' streams stream only I-frames, which are a subset of the entire video data that's streamed in normal playback mode. (E.g. in 6x fast-forward more, we stream every 6th I-frame, but nothing else, at 6x the normal rate.) The problem, however, is that the current implementation transmits 'trick mode' streams in a very bursty fashion, and this is apparently overwhelming the limited buffer space of some clients. (Some people have reported the same problem with excessively VBR files even in normal playback mode.) As previously dscussed on this mailing list, we have a solution in mind (it will require updating the index file format to include a new 'duration' field, and implement a new Transport Stream 'framer' class that uses this). There is currently no ETA for this, though. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Apr 9 11:07:52 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2007 11:07:52 -0700 Subject: [Live-devel] Undereferenced sessions In-Reply-To: <461A78E5.6000901@crystalballinc.com> References: <461A78E5.6000901@crystalballinc.com> Message-ID: >In ServerMediaSession, fDeleteWhenUnreferenced is always False and there >is no way to set it True. This means that in >RTSPServer::RTSPClientSession::~RTSPClientSession() > >if (fOurServerMediaSession->referenceCount() == 0 > && fOurServerMediaSession->deleteWhenUnreferenced()) > >is awlays false and current session is never freed, or i miss something. Yes, you missed that it's set to true in "RTSPServer::removeServerMediaSession()", if the "ServerMediaSession" object is currently in use (i.e., currently has clients). >I extend ServerMediaSession class with my own and log new and delete and > i see new allocations but never see destructor is being called. "ServerMediaSession" objects are removed/deleted as a result of "RTSPServer::removeServerMediaSession()" being called. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vlad at crystalballinc.com Mon Apr 9 11:35:32 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Mon, 09 Apr 2007 14:35:32 -0400 Subject: [Live-devel] Undereferenced sessions In-Reply-To: <461A78E5.6000901@crystalballinc.com> References: <461A78E5.6000901@crystalballinc.com> Message-ID: <461A8774.70900@crystalballinc.com> Actually it is set to True in removeServerMediaSession but in RTSPServer::RTSPClientSession::~RTSPClientSession() it is called when fOurServerMediaSession->deleteWhenUnreferenced()) is already True, so catch22. So in my code i added sms->deleteWhenUnreferenced() = True; before adding it into the server and now it is deallocated properly. May be it is better to set it by default to True? Vlad Seryakov wrote: > Hi, > > In ServerMediaSession, fDeleteWhenUnreferenced is always False and there > is no way to set it True. This means that in > RTSPServer::RTSPClientSession::~RTSPClientSession() > > if (fOurServerMediaSession->referenceCount() == 0 > && fOurServerMediaSession->deleteWhenUnreferenced()) > > is awlays false and current session is never freed, or i miss something. > I extend ServerMediaSession class with my own and log new and delete and > i see new allocations but never see destructor is being called. > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From vlad at crystalballinc.com Mon Apr 9 11:42:03 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Mon, 09 Apr 2007 14:42:03 -0400 Subject: [Live-devel] Benchmarking Message-ID: <461A88FB.4080607@crystalballinc.com> Have anyone done any benchmarks of live streaming? I just did it today on my Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz Linux box, both CPUs enabled with 2Gb of memory. I streamed 100 clients with openRTSP from another similar computer over 1 Gbit network. With one process for 100 clients, when i fired vlc i could not watch the clip, lots of lost frames. With 50 clients in one process vlc played well. So i used 2 processes with 50 streams each, and it worked pretty well, linux was not busy. I streamed same file, so disk activity was not a problem, i assume it will in case of 100 different files. Even with completely cached file, it seems to me that delay while scanning all sockets gets pretty significant with large number of clients, so spawning several threads on different ports could be the only choice to support many streams. From vlad at crystalballinc.com Mon Apr 9 12:33:59 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Mon, 09 Apr 2007 15:33:59 -0400 Subject: [Live-devel] Undereferenced sessions In-Reply-To: References: <461A78E5.6000901@crystalballinc.com> Message-ID: <461A9527.1000707@crystalballinc.com> Yes, i found in my code i called lookup with wrong name so streams got duplicated. Now it works fine and session reuse works as well. Thanks Ross Finlayson wrote: >> In ServerMediaSession, fDeleteWhenUnreferenced is always False and there >> is no way to set it True. This means that in >> RTSPServer::RTSPClientSession::~RTSPClientSession() >> >> if (fOurServerMediaSession->referenceCount() == 0 >> && fOurServerMediaSession->deleteWhenUnreferenced()) >> >> is awlays false and current session is never freed, or i miss something. > > Yes, you missed that it's set to true in > "RTSPServer::removeServerMediaSession()", if the "ServerMediaSession" > object is currently in use (i.e., currently has clients). > >> I extend ServerMediaSession class with my own and log new and delete and >> i see new allocations but never see destructor is being called. > > "ServerMediaSession" objects are removed/deleted as a result of > "RTSPServer::removeServerMediaSession()" being called. From finlayson at live555.com Mon Apr 9 15:53:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Apr 2007 15:53:15 -0700 Subject: [Live-devel] Benchmarking In-Reply-To: <461A88FB.4080607@crystalballinc.com> References: <461A88FB.4080607@crystalballinc.com> Message-ID: >Even with completely cached file, it seems to me that delay while >scanning all sockets Sets of sockets aren't 'scanned' anywhere in the code. Instead, the event loop is implemented (by default, with the "BasicTaskScheduler" class) using "select()", which should be efficient even with large numbers of readable sockets. It's possible, however, that with large numbers of open sockets, you might be running into some OS-imposed limit that could be hurting performance. I think Linux has ways of configuring the OS to support more open sockets, so that's something that you might want to look into. (Also, re. 'benchmarking' in general: Remember, You Have Complete Source Code.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vlad at crystalballinc.com Mon Apr 9 16:14:43 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Mon, 09 Apr 2007 19:14:43 -0400 Subject: [Live-devel] Benchmarking In-Reply-To: References: <461A88FB.4080607@crystalballinc.com> Message-ID: <461AC8E3.3060100@crystalballinc.com> Ross Finlayson wrote: >> Even with completely cached file, it seems to me that delay while >> scanning all sockets > > Sets of sockets aren't 'scanned' anywhere in the code. Instead, the > event loop is implemented (by default, with the "BasicTaskScheduler" > class) using "select()", which should be efficient even with large > numbers of readable sockets. > > It's possible, however, that with large numbers of open sockets, you > might be running into some OS-imposed limit that could be hurting > performance. I think Linux has ways of configuring the OS to support > more open sockets, so that's something that you might want to look > into. Yes, i meant select, i am writing scheduler using poll to see if performance will increase. > (Also, re. 'benchmarking' in general: Remember, You Have Complete Source Code.) That was more informative question what others have, i am doing my own tests but it is always good to know what is going on outside my environment. From Jiri.Pinkava at vscht.cz Mon Apr 9 16:38:06 2007 From: Jiri.Pinkava at vscht.cz (Pinky) Date: Tue, 10 Apr 2007 01:38:06 +0200 Subject: [Live-devel] Benchmarking In-Reply-To: <461AC8E3.3060100@crystalballinc.com> References: <461A88FB.4080607@crystalballinc.com> <461AC8E3.3060100@crystalballinc.com> Message-ID: <20070410013806.2de98619@storage_kolej.vscht.cz> Dne Mon, 09 Apr 2007 19:14:43 -0400 Vlad Seryakov napsal(a): > > Ross Finlayson wrote: > >> Even with completely cached file, it seems to me that delay while > >> scanning all sockets > > > > Sets of sockets aren't 'scanned' anywhere in the code. Instead, > > the event loop is implemented (by default, with the > > "BasicTaskScheduler" class) using "select()", which should be > > efficient even with large numbers of readable sockets. > > > > It's possible, however, that with large numbers of open sockets, > > you might be running into some OS-imposed limit that could be > > hurting performance. I think Linux has ways of configuring the OS > > to support more open sockets, so that's something that you might > > want to look into. > > Yes, i meant select, i am writing scheduler using poll to see if > performance will increase. > > > > (Also, re. 'benchmarking' in general: Remember, You Have Complete > > Source Code.) > I have it done already and do some testing now. > That was more informative question what others have, i am doing my > own tests but it is always good to know what is going on outside my > environment. _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Tue Apr 10 05:44:34 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Apr 2007 05:44:34 -0700 Subject: [Live-devel] RTSP server extending In-Reply-To: <461A62E5.8040900@crystalballinc.com> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> Message-ID: >- Ability to re-define Authenticator, may be move authentication to the >RTSPServer Because "digest authentication" is general functionality - used with other protocols in addition to RTSP - it will remain separate from "RTSPServer". Out of curiosity, why do you want to redefine "Authenticator"? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vlad at crystalballinc.com Tue Apr 10 06:50:49 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Tue, 10 Apr 2007 09:50:49 -0400 Subject: [Live-devel] RTSP server extending In-Reply-To: References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> Message-ID: <461B9639.7050907@crystalballinc.com> I may use it in the closed network environment where i do not authenticate by user name only but using IP address and/or MAC address in addition. Ross Finlayson wrote: >> - Ability to re-define Authenticator, may be move authentication to the >> RTSPServer > > Because "digest authentication" is general functionality - used with > other protocols in addition to RTSP - it will remain separate from > "RTSPServer". > > Out of curiosity, why do you want to redefine "Authenticator"? From vahaha at pisem.net Tue Apr 10 07:13:37 2007 From: vahaha at pisem.net (Till May) Date: Tue, 10 Apr 2007 18:13:37 +0400 Subject: [Live-devel] OnDemandServer for live video Message-ID: <20070410181337.qobv6rgkkkgs0sks@www.pochta.ru> Hi list, Ross ! First of all thank you Ross for all your suggestions and for your great library ! Nowdays I can stream live video successfully and play it with QuickTime Player, but VLC does not play, to be more precisly it plays but only for a while and than stops playback. So anyway I have some other question. If I want to stream live video on demand as I figured out I should write my own *OnDemandServerMediaSubSessin class. There is no any existed class to serve live video on demand yet. Am I right ? Also, is there template class of *OnDemandServerMediaSubSessin like DeviceSource class?. Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070410/a10ff445/attachment-0001.html From vlad at crystalballinc.com Tue Apr 10 12:25:13 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Tue, 10 Apr 2007 15:25:13 -0400 Subject: [Live-devel] Benchmarking In-Reply-To: <461AC8E3.3060100@crystalballinc.com> References: <461A88FB.4080607@crystalballinc.com> <461AC8E3.3060100@crystalballinc.com> Message-ID: <461BE499.2070805@crystalballinc.com> Okay, i've been playing with different methods and here my results: - BasicTaskScheduler can handle up to 70 simultaneous streams - then i wrote another scheduler which uses poll and handles sockets differently via preallocated array, now i can handle up to 90 simultaneous streams - then i added epoll support but because epoll does not handle regular files i had to enable READ_FROM_FILES_SYNCHRONOUSLY in ByteStreamFileSource.cpp. Surprisingly i was able to stream up to 150 streams. Even when i streamed different big files to see how hard disk will be hit, vmstat showed constant block reading activity, i was able to stream 150 streams. VLC was 151 and was playing movie perfectly. Not sure these results are representative enough but looks like overhead in BasicTaskScheduler is pretty significant. On the other hand, async disk I/O should improve performance, i guess Linux cached all my files pretty well so impact of synch reads was not big. The code currently in CVS if anybody is interested in it, sugegstions improvement are welcome: http://naviserver.cvs.sourceforge.net/naviserver/modules/nsrtsp/nsrtsp.c?revision=1.3&view=markup From finlayson at live555.com Tue Apr 10 12:29:22 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Apr 2007 12:29:22 -0700 Subject: [Live-devel] OnDemandServer for live video In-Reply-To: <20070410181337.qobv6rgkkkgs0sks@www.pochta.ru> References: <20070410181337.qobv6rgkkkgs0sks@www.pochta.ru> Message-ID: >So anyway I have some other question. If I want to stream live video >on demand as I figured out I should write my own >*OnDemandServerMediaSubSessin class. No, not necessarily. Please read the FAQ - in particular, http://www.live555.com/liveMedia/faq.html#liveInput-unicast -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070410/0074f22d/attachment.html From finlayson at live555.com Tue Apr 10 12:47:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Apr 2007 12:47:57 -0700 Subject: [Live-devel] Benchmarking In-Reply-To: <461BE499.2070805@crystalballinc.com> References: <461A88FB.4080607@crystalballinc.com> <461AC8E3.3060100@crystalballinc.com> <461BE499.2070805@crystalballinc.com> Message-ID: >Not sure these results are representative enough but looks like overhead >in BasicTaskScheduler is pretty significant. More accurately, the overhead (might be) 'pretty significant' if you happen to be using an OS that implements "select()" inefficiently. I.e., any inefficiency would be a fault of the OS, not an inherent problem with the "BasicTaskScheduler" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vlad at crystalballinc.com Tue Apr 10 12:58:22 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Tue, 10 Apr 2007 15:58:22 -0400 Subject: [Live-devel] Benchmarking In-Reply-To: References: <461A88FB.4080607@crystalballinc.com> <461AC8E3.3060100@crystalballinc.com> <461BE499.2070805@crystalballinc.com> Message-ID: <461BEC5E.3060001@crystalballinc.com> Ross Finlayson wrote: >> Not sure these results are representative enough but looks like overhead >> in BasicTaskScheduler is pretty significant. > > More accurately, the overhead (might be) 'pretty significant' if you > happen to be using an OS that implements "select()" inefficiently. > I.e., any inefficiency would be a fault of the OS, not an inherent > problem with the "BasicTaskScheduler" code. Sure, i meant exactly that. Also it is common knowledge that select/pool behave poorly in case if large number of sockets, at least in Linux, that's why epoll was introduced and kqueue in FreeBSD world. Solaris poll is more effective than in Linux. Sadly, epoll does not handle disk files. From mathew.hounsell at avegasystems.com Tue Apr 10 23:32:34 2007 From: mathew.hounsell at avegasystems.com (Mathew Hounsell) Date: Wed, 11 Apr 2007 16:32:34 +1000 Subject: [Live-devel] Wild RTSP Streams? Message-ID: <461C8102.9080000@avegasystems.com> I have used live555 to receive an RTSP/RTP/MP3 stream from the live555 server. However all the wild ones I know of are RTSP/RDP/RA. So does anyone know of some wild (radio) RTSP streams? My player supports some other audio codecs, but not RA yet. From julian.lamberty at mytum.de Wed Apr 11 07:15:19 2007 From: julian.lamberty at mytum.de (Julian Lamberty) Date: Wed, 11 Apr 2007 16:15:19 +0200 Subject: [Live-devel] Encapsulating an ffmpeg transcoder Message-ID: <461CED77.8060303@mytum.de> i there! I'm trying to transcode an RTP stream (MPEG2) on the fly via ffmpeg (into MPEG4) and stream the result via RTP again. Which Sources/Sinks should I use? Is an RTPSource/Sink the right one? But what I'm basically missing is an idea, where exactly the ffmpeg part has to be put. If I look at the test progs I think I should use the FramedSource class, is that correct? Do I have to modify (or write my own) FramedSource with an encapsulated ffmpeg-transcoder? Thanks for your help. Julian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5198 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.live555.com/pipermail/live-devel/attachments/20070411/9109828d/attachment.bin From xcsmith at rockwellcollins.com Wed Apr 11 08:02:14 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 11 Apr 2007 10:02:14 -0500 Subject: [Live-devel] Benchmarking Message-ID: Surprisingly i was able to stream up to 150 streams. Even when i streamed different big files to see how hard disk will be hit, vmstat showed constant block reading activity, i was able to stream 150 streams. VLC was 151 and was playing movie perfectly. Re: Did you do any benchmarking in which you were recording the data as well? For some reason I am losing incoming RTP data on my embedded hardware, but it does not seem to be because I cannot write fast enough. I wonder if something like your epoll program could be good for me to try? Thanks! Xochitl From vlad at crystalballinc.com Wed Apr 11 10:04:58 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Wed, 11 Apr 2007 13:04:58 -0400 Subject: [Live-devel] Benchmarking In-Reply-To: References: Message-ID: <461D153A.6010508@crystalballinc.com> My server is regular HP desktop, so for 150 i only got with epoll patch. Try it, it is module for another server but you can extract the RTSPTaskSchedule class and use it in your program xcsmith at rockwellcollins.com wrote: > Surprisingly i was able to stream up to 150 > streams. Even when i streamed different big files to see how hard disk > will be hit, vmstat showed constant block reading activity, i was able > to stream 150 streams. VLC was 151 and was playing movie perfectly. > > Re: Did you do any benchmarking in which you were recording the data as > well? For some reason I am losing incoming RTP data on my embedded > hardware, but it does not seem to be because I cannot write fast enough. I > wonder if something like your epoll program could be good for me to try? > > Thanks! > Xochitl > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From finlayson at live555.com Wed Apr 11 11:50:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 11 Apr 2007 11:50:23 -0700 Subject: [Live-devel] Benchmarking In-Reply-To: References: Message-ID: >For some reason I am losing incoming RTP data on my embedded >hardware Try calling "increaseReceiveBufferTo()" on the socket with a value larger than the default (51200==50*1024, called in "MultiFramedRTPSource.cpp", line 73). This call sets the size of the OS's internal buffer for receiving incoming packets. (E.g., VLC sets this buffer size to 100,000 bytes for audio streams, and 2,000,000 bytes for video streams.) You may find that by increasing this buffer size, the OS will be able to store any incoming packets while it's busy doing disk I/O. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Apr 11 11:52:34 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 11 Apr 2007 11:52:34 -0700 Subject: [Live-devel] Encapsulating an ffmpeg transcoder In-Reply-To: <461CED77.8060303@mytum.de> References: <461CED77.8060303@mytum.de> Message-ID: >I'm trying to transcode an RTP stream (MPEG2) on the fly via ffmpeg >(into MPEG4) and stream the result via RTP again. > >Which Sources/Sinks should I use? Is an RTPSource/Sink the right one? > >But what I'm basically missing is an idea, where exactly the ffmpeg >part has to be put. If I look at the test progs I think I should use >the FramedSource class, is that correct? Yes - more precisely, you would need to write your own subclass of "FramedFilter" to do the transcoding. I.e., your chain of objects would be: RTPSource(subclass) -> your FramedFilter subclass -> RTPSink(subclass) > >Do I have to modify (or write my own) FramedSource with an >encapsulated ffmpeg-transcoder? Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Wed Apr 11 12:31:29 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 11 Apr 2007 14:31:29 -0500 Subject: [Live-devel] Benchmarking Message-ID: Try calling "increaseReceiveBufferTo()" on the socket with a value larger than the default (51200==50*1024, called in "MultiFramedRTPSource.cpp", line 73). This call sets the size of the OS's internal buffer for receiving incoming packets. Re: I have already increased this buffer to 102,400,000. I am checking the return value of the increaceReceiveBufferTo() function also to see that the buffer was changed correctly. I decided to make it rediculously huge to see if it helped. Changing the buffer size does help, but it does not fix the problem. RTCP RR still reports periodic packet loss - even when writing to /dev/null. I edited MultiFramedRTPSource to print out the RTP ReorderingPacketBuffer.fNextExpectedSeqNo when this happens and verified that the missing RTP packets existed using ethereal. I think you suggested changing the buffer size to me before when I was asking about missing RTP packets a couple of months ago. I do not think the problem is with the LIVE, so I am reaching a lot to think about things which could be OS related, like this information about select being slow. Xochitl From finlayson at live555.com Wed Apr 11 12:35:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 11 Apr 2007 12:35:53 -0700 Subject: [Live-devel] Benchmarking In-Reply-To: References: Message-ID: >I do not think the problem is with the >LIVE, so I am reaching a lot to think about things which could be OS >related, like this information about select being slow. Or maybe you really are experiencing network packet loss... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chas.bryant at gmail.com Wed Apr 11 13:06:17 2007 From: chas.bryant at gmail.com (Chuck Bryant) Date: Wed, 11 Apr 2007 15:06:17 -0500 Subject: [Live-devel] testOnDemandRTSPServer Message-ID: I have some movie trailers (MPEG2) that I want to stream. I believe they are program files... When I try to stream with testOnDemandRTSPServer (by renaming the file to test.mpg) I get alot of: StreamParser::ParsePESPacket(): saw inconsistent PES_packet_length 0 < 8 (or 13) I read where Ross had said that the MPEG parsing code is complaining about the input data. These will play fine in VLC client (going straight to the file) as well as Winamp, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070411/26e785f7/attachment.html From xcsmith at rockwellcollins.com Wed Apr 11 13:55:03 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 11 Apr 2007 15:55:03 -0500 Subject: [Live-devel] Benchmarking Message-ID: Or maybe you really are experiencing network packet loss... ... On a private router with 1 host, 1 embedded target, & 1 RTSP server sending 1x 5 Mbps multicast stream? On a crossover cable between RTSP server and host machine? If I can see the multicast packet with the correct RTP sequence number using ethereal on the host machine, doesn't that mean the packet was not lost by the network? In what ways does a packet get lost by the network? I thought it would be something like packets expiring because of too many hops or maybe too much network data. xochitl From finlayson at live555.com Wed Apr 11 14:45:51 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 11 Apr 2007 14:45:51 -0700 Subject: [Live-devel] Benchmarking In-Reply-To: References: Message-ID: >If I can see the multicast packet with the >correct RTP sequence number using ethereal on the host machine, doesn't >that mean the packet was not lost by the network? If by "the host machine" you mean the receiving machine, then yes, if "etherial" sees the incoming packet, then (of course) it was not lost by the network. If "etherial" sees the incoming packet, but the "LIVE555 Streaming Media" code does not, then the loss *must* be happening within your OS kernel - so that's where you'll need to look next. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Apr 11 17:18:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 11 Apr 2007 17:18:06 -0700 Subject: [Live-devel] testOnDemandRTSPServer In-Reply-To: References: Message-ID: >I have some movie trailers (MPEG2) that I want to stream. I >believe they are program files... When I try to stream with >testOnDemandRTSPServer (by renaming the file to test.mpg) I get alot >of: > >StreamParser::ParsePESPacket(): saw inconsistent PES_packet_length 0 >< 8 (or 13) Please put one of these files on a web server, and send us the URL, so I can download it and check it myself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070411/6b6d64d8/attachment.html From vahaha at pisem.net Wed Apr 11 22:40:35 2007 From: vahaha at pisem.net (Till May) Date: Thu, 12 Apr 2007 09:40:35 +0400 Subject: [Live-devel] Benchmarking Message-ID: <20070412094035.3ic0c11kgowww8sk@www.pochta.ru> Howdy List ! I think I have the same problem as xcsmith. When I stream live video to local network (20 hosts) on the clients side QuickTime recieves and plays the video. But at the moment only 2-3 clients can play. Others just showing some first recieved frame and stays along, but they continue to recieve packets (I see that in statistics of players, where bps of stream is shown, etc). Also I see the multicast packets with the correct RTP sequence number using Ethereal on the clients machine. When I restart thise bazzed clients the others that plays stream hangs on with current played frame, but still continues recieving stream... What's wrong I dont know %))) ? Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070411/d3697800/attachment.html From rmpg2001 at gmail.com Thu Apr 12 01:23:14 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Thu, 12 Apr 2007 10:23:14 +0200 Subject: [Live-devel] Stop Playing Message-ID: <389189e20704120123n29a742e2lefa56e42b74d6947@mail.gmail.com> Hi all, I have an application that streams broadcast H.264 video. I have a thread that is waiting for commands and it changes the watchVariable ("env->taskScheduler().doEventLoop(&watchVariable);"), so it outs EventLoop, executes the command the value of watchVariable indicates and then return to EventLoop. One of this commands has to stop streaming and then delete session. I would like to know what is the best way to do that. I proved to use VideoSink->stopPlaying() but I see this is a private void, so I thought I wasn't going by the right way. Thanks in advance, Ramon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070412/e7024e18/attachment.html From finlayson at live555.com Thu Apr 12 01:54:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Apr 2007 01:54:06 -0700 Subject: [Live-devel] Stop Playing In-Reply-To: <389189e20704120123n29a742e2lefa56e42b74d6947@mail.gmail.com> References: <389189e20704120123n29a742e2lefa56e42b74d6947@mail.gmail.com> Message-ID: >One of this commands has to stop streaming and then delete session. >I would like to know what is the best way to do that. I proved to >use VideoSink->stopPlaying() but I see this is a private void, so I >thought I wasn't going by the right way. No, calling "stopPlaying()" is correct. If you cast your 'sink' object (pointer) to a "(MediaSink*)" before calling "stopPlaying()", you'll be able to do this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yossydr at gmail.com Thu Apr 12 02:30:01 2007 From: yossydr at gmail.com (yossy) Date: Thu, 12 Apr 2007 12:30:01 +0300 Subject: [Live-devel] transmit multiple streams concurrently Message-ID: <461DFC19.4060301@gmail.com> Hi all, How can i transmit multiple MPEG-4 files concurrently with one server? Do i need to define different port for each file? From rmpg2001 at gmail.com Thu Apr 12 03:22:29 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Thu, 12 Apr 2007 12:22:29 +0200 Subject: [Live-devel] Stop Playing In-Reply-To: References: <389189e20704120123n29a742e2lefa56e42b74d6947@mail.gmail.com> Message-ID: <389189e20704120322n7fb84021od669b0bbb7280189@mail.gmail.com> Thanks for your response, Ross. Now, my problem is that it breaks down the application. Do you know what could be the problem. Should I close session too, close the source or indicate to the environment that this sink is stopped? Ramon 2007/4/12, Ross Finlayson : > > >One of this commands has to stop streaming and then delete session. > >I would like to know what is the best way to do that. I proved to > >use VideoSink->stopPlaying() but I see this is a private void, so I > >thought I wasn't going by the right way. > > No, calling "stopPlaying()" is correct. If you cast your 'sink' > object (pointer) to a "(MediaSink*)" before calling "stopPlaying()", > you'll be able to do this. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070412/c4accbde/attachment-0001.html From finlayson at live555.com Thu Apr 12 06:24:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Apr 2007 06:24:31 -0700 Subject: [Live-devel] transmit multiple streams concurrently In-Reply-To: <461DFC19.4060301@gmail.com> References: <461DFC19.4060301@gmail.com> Message-ID: >How can i transmit multiple MPEG-4 files concurrently with one server? >Do i need to define different port for each file? Yes, of course. (If you're transmitting the data via unicast, on demand, then this happens automatically.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chas.bryant at gmail.com Thu Apr 12 09:32:47 2007 From: chas.bryant at gmail.com (Chuck Bryant) Date: Thu, 12 Apr 2007 11:32:47 -0500 Subject: [Live-devel] testOnDemandRTSPServer In-Reply-To: References: Message-ID: Thanks Ross, but I got lucky this time. Seems the movie I was working with was already in transport stream, and I didn't know it because it was labeled "mpg". So that all works fine with Amino boxes now. Now I was wondering if I can transcode from mp4 to mpeg2 TS on the fly? Do you think it would be too processor intensive? On 4/11/07, Ross Finlayson wrote: > > I have some movie trailers (MPEG2) that I want to stream. I believe > they are program files... When I try to stream with testOnDemandRTSPServer > (by renaming the file to test.mpg) I get alot of: > > > > StreamParser::ParsePESPacket(): saw inconsistent PES_packet_length 0 < 8 > (or 13) > > > > Please put one of these files on a web server, and send us the URL, so I > can download it and check it myself. > > -- > > > 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: http://lists.live555.com/pipermail/live-devel/attachments/20070412/8cfce300/attachment.html From morgan.torvolt at gmail.com Thu Apr 12 10:34:40 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 12 Apr 2007 21:34:40 +0400 Subject: [Live-devel] Trick play and reuseFirstSource Message-ID: <3cc3561f0704121034o6df1e4a3he6aef97b37ef1ba9@mail.gmail.com> Hi In MPEG2TransportFileServerMediaSubsession, would it not make sense to check if reuseFirstSource is set, and load the index file (if it exists) in case it is not. I believe that the way it is now, you will have to remove the index file to be able to use the source file as a reusable source. I could be reading the code wrongly though. -Morgan- From finlayson at live555.com Thu Apr 12 12:06:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Apr 2007 12:06:55 -0700 Subject: [Live-devel] Trick play and reuseFirstSource In-Reply-To: <3cc3561f0704121034o6df1e4a3he6aef97b37ef1ba9@mail.gmail.com> References: <3cc3561f0704121034o6df1e4a3he6aef97b37ef1ba9@mail.gmail.com> Message-ID: >In MPEG2TransportFileServerMediaSubsession, would it not make sense >to check if reuseFirstSource is set, and load the index file (if it >exists) in case it is not. I believe that the way it is now, you will >have to remove the index file to be able to use the source file as a >reusable source. Yes, and IMHO that's appropriate. If you've created an index file for a TS file, then that implies that you intend to support 'trick play' operations on it - therefore you don't want to stream it as if it were a live source. I.e., the presence of the index file takes priority in figuring out what's intended. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Thu Apr 12 22:02:01 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Fri, 13 Apr 2007 09:02:01 +0400 Subject: [Live-devel] Trick play and reuseFirstSource In-Reply-To: References: <3cc3561f0704121034o6df1e4a3he6aef97b37ef1ba9@mail.gmail.com> Message-ID: <3cc3561f0704122202n5ef39e2fq8c9fcfbf815b9a91@mail.gmail.com> > Yes, and IMHO that's appropriate. If you've created an index file > for a TS file, then that implies that you intend to support 'trick > play' operations on it - therefore you don't want to stream it as if > it were a live source. I.e., the presence of the index file takes > priority in figuring out what's intended. I would have to disagree with you on that. What if I would like to use one source file for two different uses? Say one fixed time playout and one trick play capable version so that I can do differing of the price on the two types. A couple of points to consider - The reuseFirstSource is a more specific command than having an index file, and should be the one that takes priority. (In CSS the case would be closed here) - The index file could be generated on every .ts file uploaded to the server. It does not make sense to me to have to implement a check in the file upload system to handle a option that is given in a completely different program. - Would a programmer that is not explicitly aware of this expect the current behavour? - If one where to add a index file to be able to use the source file for trick play, one would with that change behavour of existing and working software, possibly rendering it unusable. - Whenever I set an option in any program I use, I expect it to do what I tell it to do every time, or never if it is not possible. That some external entity can come and overrule my setting by simply indexing a file would be confusing, and probably give me a lot of debugging befor I would get really mad, and write a e-mail much less polite than this one =) - It is rude for a program to say "I am more intelligent than you, and I disregard what you are asking me to do and will do something completely different instead". - How could the library know what was intended? Would not that be something for the user/programmer to decide? If the reuseFirstSource is set, would you not think that would be what the current user of the .ts file would want? I think the way it works now is bad. It feels like random, and out of my control. If the file was situated on a networked drive, the bahveour of my code would be dependent upon what the guy who uploaded the file have done when he uploaded it. Having it the current way demands that external software and other system management staff must be aware of the use of the file, and makes it impossible to use the file for the two different purposes I described. In other words, the current implementation is limiting, and I don't like that. If I did, I would be writing this e-mail using windows, and maybe even outlook. No... That would be too crazy. =) Regards -Morgan- From finlayson at live555.com Fri Apr 13 00:19:08 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Apr 2007 00:19:08 -0700 Subject: [Live-devel] Trick play and reuseFirstSource In-Reply-To: <3cc3561f0704122202n5ef39e2fq8c9fcfbf815b9a91@mail.gmail.com> References: <3cc3561f0704121034o6df1e4a3he6aef97b37ef1ba9@mail.gmail.com> <3cc3561f0704122202n5ef39e2fq8c9fcfbf815b9a91@mail.gmail.com> Message-ID: Well, I don't agree with many of your arguments (especially the one about "using one source file for two different uses" - you could use different file names (which you'd probably need to do anyway), using symbolic links). However, since you're the only person who seems to care passionately about this, I'll make the change in the next release of the software - so that it ignores any index file if "reuseFirstSource" is set. (I'm still not sure why anyone would want to set "reuseFirstSource" on a non-live stream, but whatever...) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rmpg2001 at gmail.com Fri Apr 13 02:06:39 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Fri, 13 Apr 2007 11:06:39 +0200 Subject: [Live-devel] Stop Playing In-Reply-To: <389189e20704120322n7fb84021od669b0bbb7280189@mail.gmail.com> References: <389189e20704120123n29a742e2lefa56e42b74d6947@mail.gmail.com> <389189e20704120322n7fb84021od669b0bbb7280189@mail.gmail.com> Message-ID: <389189e20704130206r1764bea5p8f779f30c68723bf@mail.gmail.com> Hi, I resolved it, but it still send RTCP packets from this session so I tried to close session. I thought using: static void close( UsageEnvironment& env, char const *mediumName) but I don't undestand what's mediumName variable. Is it the best way to close my session? Thanks in advance, Ramon 2007/4/12, Ramon Martin de Pozuelo : > > Thanks for your response, Ross. Now, my problem is that it breaks down the > application. Do you know what could be the problem. Should I close session > too, close the source or indicate to the environment that this sink is > stopped? > > Ramon > > 2007/4/12, Ross Finlayson : > > > > >One of this commands has to stop streaming and then delete session. > > >I would like to know what is the best way to do that. I proved to > > >use VideoSink->stopPlaying() but I see this is a private void, so I > > >thought I wasn't going by the right way. > > > > No, calling "stopPlaying()" is correct. If you cast your 'sink' > > object (pointer) to a "(MediaSink*)" before calling "stopPlaying()", > > you'll be able to do this. > > -- > > > > Ross Finlayson > > Live Networks, Inc. > > http://www.live555.com/ > > _______________________________________________ > > live-devel mailing list > > live-devel at lists.live555.com > > http://lists.live555.com/mailman/listinfo/live-devel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070413/1e4e407a/attachment.html From rmpg2001 at gmail.com Fri Apr 13 02:16:03 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Fri, 13 Apr 2007 11:16:03 +0200 Subject: [Live-devel] Stop Playing In-Reply-To: <389189e20704130206r1764bea5p8f779f30c68723bf@mail.gmail.com> References: <389189e20704120123n29a742e2lefa56e42b74d6947@mail.gmail.com> <389189e20704120322n7fb84021od669b0bbb7280189@mail.gmail.com> <389189e20704130206r1764bea5p8f779f30c68723bf@mail.gmail.com> Message-ID: <389189e20704130216y50ec4191m1662b7546dd3ef8b@mail.gmail.com> Sorry, I would have said: static void close( UsageEnvironmeng &env, char const *mediumName) 2007/4/13, Ramon Martin de Pozuelo : > > Hi, > I resolved it, but it still send RTCP packets from this session so I tried > to close session. I thought using: > > static void close( > UsageEnvironment& > env, char const *mediumName) > > but I don't undestand what's mediumName variable. > > Is it the best way to close my session? > > Thanks in advance, > > Ramon > > 2007/4/12, Ramon Martin de Pozuelo : > > > > Thanks for your response, Ross. Now, my problem is that it breaks down > > the application. Do you know what could be the problem. Should I close > > session too, close the source or indicate to the environment that this sink > > is stopped? > > > > Ramon > > > > 2007/4/12, Ross Finlayson : > > > > > > >One of this commands has to stop streaming and then delete session. > > > >I would like to know what is the best way to do that. I proved to > > > >use VideoSink->stopPlaying() but I see this is a private void, so I > > > >thought I wasn't going by the right way. > > > > > > No, calling "stopPlaying()" is correct. If you cast your 'sink' > > > object (pointer) to a "(MediaSink*)" before calling "stopPlaying()", > > > you'll be able to do this. > > > -- > > > > > > Ross Finlayson > > > Live Networks, Inc. > > > http://www.live555.com/ > > > _______________________________________________ > > > live-devel mailing list > > > live-devel at lists.live555.com > > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070413/12885626/attachment-0001.html From finlayson at live555.com Fri Apr 13 02:30:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Apr 2007 02:30:31 -0700 Subject: [Live-devel] Stop Playing In-Reply-To: <389189e20704130206r1764bea5p8f779f30c68723bf@mail.gmail.com> References: <389189e20704120123n29a742e2lefa56e42b74d6947@mail.gmail.com> <389189e20704120322n7fb84021od669b0bbb7280189@mail.gmail.com> <389189e20704130206r1764bea5p8f779f30c68723bf@mail.gmail.com> Message-ID: >Is it the best way to close my session? After calling yourSink->stopPlaying(); call Medium:close(yourSink); Medium::close(theSourceThatYourSinkWasBeingPlayedFrom); Search for "Medum::close" in the "testProgs" directory; there are many examples. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Fri Apr 13 08:30:04 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Fri, 13 Apr 2007 10:30:04 -0500 Subject: [Live-devel] Trick play and reuseFirstSource Message-ID: (I'm still not sure why anyone would want to set "reuseFirstSource" on a non-live stream, but whatever...) -- Re: Would it be useful for remote training purposes? If I am understanding what you mean correctly, then I could easily see hardcore MMO gamers getting in ventrillo together and then watching the same strategy video at the same time, occasionally pausing it for discussion or going back over part of it that was missed because someone was being obnoxious. :) Maybe not the best example, but really hardcore guilds do all kinds of stuff like this. If I was still gaming, I would want to do this in my guild to review and discuss raid strategy with other guild leaders. Anyway, it might be possible to build an interesting mentoring tool if trick play and reuseFirstSource can be enabled at the same time. Xochitl From shalom.shushan at gmail.com Fri Apr 13 15:11:05 2007 From: shalom.shushan at gmail.com (shalom shushan) Date: Sat, 14 Apr 2007 01:11:05 +0300 Subject: [Live-devel] transmit multiple streams concurrently In-Reply-To: References: <461DFC19.4060301@gmail.com> Message-ID: Hi Ross, I'm also streaming multiple MPEG4 files via unicast, on demand. I want to have indication of what stream the client is asking to play in my server. Is there any variable that i can use by simply "printf" this variable? Do i need to define such variable that in any client request to play the stream will give me indication which stream is asked? where or how should i define such a variable? Thanks Orit On 4/12/07, Ross Finlayson wrote: > > >How can i transmit multiple MPEG-4 files concurrently with one server? > >Do i need to define different port for each file? > > Yes, of course. > > (If you're transmitting the data via unicast, on demand, then this > happens automatically.) > -- > > 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: http://lists.live555.com/pipermail/live-devel/attachments/20070413/6df68ffa/attachment.html From finlayson at live555.com Fri Apr 13 16:22:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Apr 2007 16:22:39 -0700 Subject: [Live-devel] transmit multiple streams concurrently In-Reply-To: References: <461DFC19.4060301@gmail.com> Message-ID: >I'm also streaming multiple MPEG4 files via unicast, on demand. I hope you realize that our RTSP server implementation (e.g., as used in the "LIVE555 Media Server" ) does this automatically. You don't need to write any new code to do this. >I want to have indication of what stream the client is asking to >play in my server. I'm not sure I understand your question, but I suggest using "openRTSP" (with the -V option) as your RTSP client . This will show you what is going on. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From shalom.shushan at gmail.com Fri Apr 13 23:55:27 2007 From: shalom.shushan at gmail.com (shalom shushan) Date: Sat, 14 Apr 2007 08:55:27 +0200 Subject: [Live-devel] transmit multiple streams concurrently In-Reply-To: References: <461DFC19.4060301@gmail.com> Message-ID: Ross, i will be more clear: The server side is my application based on the on-demand test program. I need some indication on the server side which stream is played by any client (i don't control the client side). On 4/14/07, Ross Finlayson wrote: > > >I'm also streaming multiple MPEG4 files via unicast, on demand. > > I hope you realize that our RTSP server implementation (e.g., as used > in the "LIVE555 Media Server" ) > does this automatically. You don't need to write any new code to do > this. > > > >I want to have indication of what stream the client is asking to > >play in my server. > > I'm not sure I understand your question, but I suggest using > "openRTSP" (with the -V option) as your RTSP client > . This will show you what is going > on. > > -- > > 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: http://lists.live555.com/pipermail/live-devel/attachments/20070413/20ee36fe/attachment.html From finlayson at live555.com Sat Apr 14 01:50:04 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 14 Apr 2007 01:50:04 -0700 Subject: [Live-devel] transmit multiple streams concurrently In-Reply-To: References: <461DFC19.4060301@gmail.com> Message-ID: >i will be more clear: >The server side is my application based on the on-demand test program. >I need some indication on the server side which stream is played by >any client Add #define DEBUG 1 to "liveMedia/RTSPServer.cpp", and recompile. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From weiyutao36 at 163.com Sat Apr 14 02:31:35 2007 From: weiyutao36 at 163.com (weiyutao36) Date: Sat, 14 Apr 2007 17:31:35 +0800 (CST) Subject: [Live-devel] How much clients can live server support at the same time? Message-ID: <18147224.1478241176543095232.JavaMail.root@bj163app55.163.com> Hi Ross,Does live library, e.g.,testOndemandRTSPServer has a limit on the number of concurrent clients? I want to know how much clients at maximum testOndemandRTSPServer can support. Thanks a lot. Yutao Wei -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070414/199b03b6/attachment.html From finlayson at live555.com Sat Apr 14 05:24:03 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 14 Apr 2007 05:24:03 -0700 Subject: [Live-devel] How much clients can live server support at the same time? In-Reply-To: <18147224.1478241176543095232.JavaMail.root@bj163app55.163.com> References: <18147224.1478241176543095232.JavaMail.root@bj163app55.163.com> Message-ID: Does live library, e.g.,testOndemandRTSPServer has a limit on the number of concurrent clients? No, there is no such limit in the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Mon Apr 16 03:55:16 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 16 Apr 2007 14:55:16 +0400 Subject: [Live-devel] Trick play problems. Message-ID: <3cc3561f0704160355i680fc9f4x4a306d12bd0ae94d@mail.gmail.com> Hi I have indexed a .ts file of mine to test out the trick play functionality. The index file seems fine, and using ./testMPEG2TransportStreamTrickPlay everything works just fine. Trick play is flawless using the output file to play in vlc and on our STB. So my next step was testing the trick play using testOnDemandRTSPServer. That did not go so well. Whenever I change scale with my STB, the application completely stops sending data, and goes to the singlestep loop. Even if I request scale=1 again by pressing the play button. I was thinking that this was probably caused by the STB, so I added full debug output to see what was happening, as well as DEBUG_PCR. There are no PCR debug output at all after changing scale, so I guess there is no data going trough the transport stream framer at all. I used a few different source files, including this file: http://samples.mplayerhq.hu/MPEG2/TITLE01-ANGLE2.VOB All without success. I have the latest source from this folder: http://www.live555.com/liveMedia/public/ To make sure that it was not me messing things up (or at least make it less likely) i changed the code in RTSPClient.cpp to set a default scale to 5.0f, 5.0 and 5 (tried them all), and get the same results. When I start openRTSP it connects and everything, but no PCR debug output, and no datarate going trough the networking interfaces, as well as no data in the output file form openRTSP. I am a bit at a loss here. What could be causing this? I wanted to revert to the previous version of live to see if that made a difference, but I found no change. -Morgan- From finlayson at live555.com Mon Apr 16 07:13:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Apr 2007 07:13:01 -0700 Subject: [Live-devel] Trick play problems. In-Reply-To: <3cc3561f0704160355i680fc9f4x4a306d12bd0ae94d@mail.gmail.com> References: <3cc3561f0704160355i680fc9f4x4a306d12bd0ae94d@mail.gmail.com> Message-ID: >I used a few different source files, including this file: >http://samples.mplayerhq.hu/MPEG2/TITLE01-ANGLE2.VOB >All without success. You realize, I hope, that ".VOB" files are MPEG *Program Stream* files, not Transport Stream files, and therefore you won't be able to create index files from them (or, currently, stream them with scale != 1). Can you point us at an example of a *Transport Stream* file that illustrates your problem? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Mon Apr 16 08:01:48 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 16 Apr 2007 19:01:48 +0400 Subject: [Live-devel] Trick play problems. In-Reply-To: References: <3cc3561f0704160355i680fc9f4x4a306d12bd0ae94d@mail.gmail.com> Message-ID: <3cc3561f0704160801x59d7db11n809ca771ec3b060a@mail.gmail.com> Hi again. Ah, but of course I should have specified this. I made a .ts file of it using your testMPEG1or2ProgramToTransportStream. I guessed that if I used your application for that, it should at least be compliant with your system. I should also specify that the same happens on three different machines with the latest library downloaded and compiled from scratch. -Morgan- On 16/04/07, Ross Finlayson wrote: > >I used a few different source files, including this file: > >http://samples.mplayerhq.hu/MPEG2/TITLE01-ANGLE2.VOB > >All without success. > > You realize, I hope, that ".VOB" files are MPEG *Program Stream* > files, not Transport Stream files, and therefore you won't be able to > create index files from them (or, currently, stream them with scale > != 1). > > Can you point us at an example of a *Transport Stream* file that > illustrates your problem? > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From finlayson at live555.com Mon Apr 16 15:35:08 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Apr 2007 15:35:08 -0700 Subject: [Live-devel] Trick play problems. In-Reply-To: <3cc3561f0704160801x59d7db11n809ca771ec3b060a@mail.gmail.com> References: <3cc3561f0704160355i680fc9f4x4a306d12bd0ae94d@mail.gmail.com> <3cc3561f0704160801x59d7db11n809ca771ec3b060a@mail.gmail.com> Message-ID: >Ah, but of course I should have specified this. I made a .ts file of >it using your testMPEG1or2ProgramToTransportStream. I guessed that if >I used your application for that, it should at least be compliant with >your system. Sorry, but I wasn't able to reproduce your problem. I did the following: 1/ Downloaded http://samples.mplayerhq.hu/MPEG2/TITLE01-ANGLE2.VOB ; renamed it to "in.mpg" 2/ Ran "testMPEG1or2ProgramToTransportStream", generating "out.ts" 3/ Ran "MPEG2TransportStreamIndexer", to generate "out.tsx" 4/ Ran "live555MediaServer" (with "out.ts" and "out.tsx" in the same directory) 5/ In the "testProgs" directory, I changed the call to "playMediaSession()" in "openRTSP.cpp" to return rtspClient->playMediaSession(*session, 0.0f, -1.0f, 5.0f); and recompiled "openRTSP". 6/ Ran "openRTSP" to stream "out.ts" from the media server. When I did this, I got an output file that correctly played in VLC - showing 5x speedup from the original. Can you describe how to reproduce your problem? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From julian.lamberty at mytum.de Wed Apr 18 02:17:25 2007 From: julian.lamberty at mytum.de (Julian Lamberty) Date: Wed, 18 Apr 2007 11:17:25 +0200 Subject: [Live-devel] Subclass FramedFilter for transcoding Message-ID: <4625E225.1000306@mytum.de> Hi! I'm still working on a solution for transcoding RTP streams. What I'm trying to achieve is: 1: Receiving one (or more) RTP/RTSP network streams 2: Feeding that streams into an ffmpeg transcoding unit 3: Streaming the transcoded content again via RTP/RTSP Thanks to your help I already tried to implement a subclass of FramedFilter to do that, but I still have several questions (maybe some of them rather ffmpeg related, but I'll try here anyway ;)): 1: What kind of "packets" does a SimpleRTPSource deliver (and what does a SimpleRTPSink expect) and how can I pass the packets/frames (?) to ffmpeg (i.e. an AVPacket)? 2: If I use an SimpleRTPSource as input and an SimpleRTPSink object as output (I try to stay general as much as possible as I want my transcoder to handle many formats), which tasks will be left to the ffmpeg part? Do I also have to care about demuxing/muxing? In principle I'm stuck at the question of how to exchange data between the livemedia part and the ffmpeg part. 3: Can I use ffmpeg to detect the format of the incoming stream? If yes, how can I get the data on initialization of the Transcoder class (I at least need one received packet, right)? 4: Last but not least a simple question concerning this mailing list: How do I reply to a post? Do I simply use "Re: ..." as subject? Thank you very much for your help! Julian Lamberty -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5198 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.live555.com/pipermail/live-devel/attachments/20070418/fab252ec/attachment.bin From david at embedded-sol.com Wed Apr 18 03:17:53 2007 From: david at embedded-sol.com (David Ohayon) Date: Wed, 18 Apr 2007 13:17:53 +0300 Subject: [Live-devel] problem when using Ethernet over USB (RNDIS) for streaming Message-ID: <006401c781a2$d440f3a0$ef00000a@david10> Hi All, ? I am using live555 to stream out JPEG images. It runs under windows CE 5.0. ? There are no problems to stream out when using an ordinary Ethernet connection. I can use VLC, mplayer and QuickTime as viewers. ? However when I switch to RNDIS (Ethernet over USB) connection it does not work any more. The output of the streamer is below. /********************************************/ RTCPInstance[001915C0]::RTCPInstance() schedule(3.029313->1041454310.029313) Play this stream using the URL "rtsp://100.0.0.130:7070/" Beginning streaming... sending REPORT sending RTCP packet 80c80006 5e9c5b68 c1bdd367 00000000 5bb97631 0000019d 0008c319 81ca0005 5e9c5b68 010c4d54 45796520 63616d65 72610000 schedule(1.583865->1041454312.583865) accept()ed connection from 100.0.0.1 RTSPClientSession[001936D0]::incomingRequestHandler1() read 198 bytes:DESCRIBE rtsp://100.0.0.130:7070/ RTSP/1.0 CSeq: 1 Accept: application/sdp Bandwidth: 384000 Accept-Language: nl-NL User-Agent: QuickTime/7.1.5 (qtver=7.1.5;os=Windows NT 5.1Service Pack 2) parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "" sending response: RTSP/1.0 200 OK CSeq: 1 Wed, Jan 01 2003 20:51:52 GMT Content-Base: rtsp://100.0.0.130:7070// Content-Type: application/sdp Content-Length: 431 v=0 o=- 1041454307000000 1 IN IP4 100.0.0.130 s=Session streamed by the SSDH camera i=SSDHStreamer t=0 0 a=tool:LIVE555 Streaming Media v2006.11.15 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * 100.0.0.130 a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:Session streamed by the MTEye camera a=x-qt-text-inf:MTeyeStreamer m=video 2222 RTP/AVP 26 c=IN IP4 232.38.112.65/255 a=control:track1 RTSPClientSession[001936D0]::incomingRequestHandler1() read 303 bytes:SETUP rtsp://100.0.0.130:7070//track1 RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=2222-2223 x-retransmit: our-retransmit x-dynamic-rate: 1 x-transport-options: late-tolerance=2.900000 User-Agent: QuickTime/7.1.5 (qtver=7.1.5;os=Windows NT 5.1Service Pack 2) Accept-Language: nl-NL parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "", urlSuffix "track1" sending response: RTSP/1.0 200 OK CSeq: 2 Wed, Jan 01 2003 20:51:52 GMT Transport: RTP/AVP;multicast;destination=232.38.112.65;port=2222-0;ttl=255 Session: 1 RTSPClientSession[001936D0]::incomingRequestHandler1() read 191 bytes:PLAY rtsp://100.0.0.130:7070/ RTSP/1.0 CSeq: 3 Range: npt=0.000000- x-prebuffer: maxtime=2.000000 Session: 1 User-Agent: QuickTime/7.1.5 (qtver=7.1.5;os=Windows NT 5.1Service Pack 2) parseRTSPRequestString() returned cmdName "PLAY", urlPreSuffix "", urlSuffix "" sending response: RTSP/1.0 200 OK CSeq: 3 Wed, Jan 01 2003 20:51:52 GMT Range: npt=0.000- Session: 1 RTP-Info: url=rtsp://100.0.0.130:7070//track1;seq=26784;rtptime=1538971073 schedule(3.349909->1041454316.349909) sending REPORT sending RTCP packet 80c80006 5e9c5b68 c1bdd36d 00000000 5bc1b391 00000451 00176d7b 81ca0005 5e9c5b68 010c4d54 45796520 63616d65 72610000 schedule(6.133813->1041454323.133813) RTSPClientSession[001936D0]::incomingRequestHandler1() read 0 bytes (of 10000); terminating connection! accept()ed connection from 100.0.0.1 RTSPClientSession[00198740]::incomingRequestHandler1() read 215 bytes:GET / HTTP/1.0 User-Agent: QuickTime/7.1.5 (qtver=7.1.5;os=Windows NT 5.1Service Pack 2) x-sessioncookie: pnuKwv/sAACQLd0BBYAAAA Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache parseRTSPRequestString() failed! sending response: RTSP/1.0 400 Bad Request Wed, Jan 01 2003 20:52:02 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE sending REPORT sending RTCP packet 80c80006 5e9c5b68 c1bdd375 00000000 5bccb011 000007ec 002aff24 81ca0005 5e9c5b68 010c4d54 45796520 63616d65 72610000 schedule(3.536260->1041454328.536260) /****************************************************/ Thanks, David From finlayson at live555.com Wed Apr 18 06:11:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Apr 2007 06:11:50 -0700 Subject: [Live-devel] problem when using Ethernet over USB (RNDIS) for streaming In-Reply-To: <006401c781a2$d440f3a0$ef00000a@david10> References: <006401c781a2$d440f3a0$ef00000a@david10> Message-ID: > I am using live555 to stream out JPEG images. It runs under windows CE >5.0. > > There are no problems to stream out when using an ordinary Ethernet >connection. I can use VLC, mplayer and QuickTime as viewers. > However when I switch to RNDIS (Ethernet over USB) connection it does not >work any more. Your problem is probably that IP multicast is not working on your new network interface - most likely because you don't have multicast routing set up to use that interface. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Apr 18 12:31:42 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Apr 2007 12:31:42 -0700 Subject: [Live-devel] Subclass FramedFilter for transcoding In-Reply-To: <4625E225.1000306@mytum.de> References: <4625E225.1000306@mytum.de> Message-ID: >1: What kind of "packets" does a SimpleRTPSource deliver (and what >does a SimpleRTPSink expect) All data in the RTP packet after the 12-byte RTP header (and any header extension). >3: Can I use ffmpeg to detect the format of the incoming stream? No. You would use "MediaSubsession::mediumName()", and "MediaSubsession::codecName()". I can't help you with questions about "ffmpeg" >4: Last but not least a simple question concerning this mailing >list: How do I reply to a post? Do I simply use "Re: ..." as subject? Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From c.drost at student.utwente.nl Thu Apr 19 02:08:19 2007 From: c.drost at student.utwente.nl (c.drost at student.utwente.nl) Date: Thu, 19 Apr 2007 11:08:19 +0200 Subject: [Live-devel] Limiting listening time on permant sdp sessions Message-ID: Hello Ross, I am using the live555 library to stream live RTP content taken from a radio station using the darwinInjector. The only problem I have is that I want to limit the listening time to half an hour using the sdp file description. Due to the fact that we are using a radio station as input, the start and end time cannot be set in the description, how can I still use the repeat field in the sdp file to "repeat" the permanent session every half an hour. E.G. a user tuning in using the sdp file cna listen for half an hour and is than cut off, reloading the sdp file result in the user being able to listen again half an hour, and so on... I am not even sure if this is possible with the repeat time field, but the sdp file looking like the one I am using now is not doing the trick (see below), got any ideas on how to insert this functionality or to get the darwinInjecor to generate behavior like this?? /*********************************/ SDP fields used regarding timing: t=0 0 r=1801 1800 /*********************************/ where t= (0 0 is permanent session) r= Regards, Chiel Drost From kittisak at jowit.com Thu Apr 19 03:13:14 2007 From: kittisak at jowit.com (Kittisak Leelathawornpanya('M')) Date: Thu, 19 Apr 2007 17:13:14 +0700 Subject: [Live-devel] How to build a video conferencing system with LiveMedia Library Message-ID: <006901c7826b$57a71df0$6a09a8c0@KITTISAKM> Hello, Ross and all of us I need your help for guiding me to build a video conferencing system with LiveMedia Library Can anyone suggest me ?.............. Regards , Faithfully yours Kittisak Leelathawornpanya _______________________________________________ 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: http://lists.live555.com/pipermail/live-devel/attachments/20070419/dfe331d0/attachment.html From cehoyos at rainbow.studorg.tuwien.ac.at Thu Apr 19 05:12:59 2007 From: cehoyos at rainbow.studorg.tuwien.ac.at (Carl Eugen Hoyos) Date: Thu, 19 Apr 2007 14:12:59 +0200 (CEST) Subject: [Live-devel] www.live555.com/mplayer Message-ID: Hi Ross! A user explained on mplayer-users last week that he wasn't able to configure mplayer the way described on http://www.live555.com/mplayer/ (He didn't say he followed your suggestions, but that's what I guessed.) The option --with-livelibdir has been removed from mplayers configure, I think --with-extraincdir= should be the correct option (I didn't try). Additionally, on mplayer mailing lists, everybody is advised not to use --enable-* (except --enable-gui, but including --enable-live), because it forces demux_rtp.cpp to be compiled, no matter if live555 library is installed or not, while that should be autodetected; so perhaps you could change the text on http://www.live555.com/mplayer to something like 3. ... run cd MPlayer* ; ./configure and check if live555 library was auto detected successfully. Otherwise, run cd MPlayer* ; ./configure --with-extraincdir= and make sure that live555 library was auto detected successfully. Thank you, Carl Eugen From l1436636 at yahoo.com Thu Apr 19 06:53:28 2007 From: l1436636 at yahoo.com (hong liu) Date: Thu, 19 Apr 2007 06:53:28 -0700 (PDT) Subject: [Live-devel] about openRTP Message-ID: <61042.54884.qm@web51101.mail.re2.yahoo.com> I have a test.mp4 file on Darwin Streaming server, which include a h264 video file and audio file. Now I want to receive the video file and output it to a file. Then I ran openRTP on my Linux machine. First I used the command of "openRTP rtsp://192.168.0.1/test.mp4", and then I got one audio file named audio-MPEG4-GENERIC-2 and one video file named video-h264-1. I tried to open video-h264-1 with vlc or mplayer, and all tries failed. I don't know what format this file is. Is it h264 elementary stream file or other format. The same happened to the audio file. Then I used the command of "openRTP -v -4 -w 176 -h 144 -f 30 rtsp://192.168.0.1/test.mp4 > test_video.mp4", and then I opened test_video.mp4 with vlc, with nothing playing back. I also used quicktime player to open it. It can be played back but there are some problems in picture reconstruction and there is audio in between. What is wrong with it. Thank you for your help! Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/709794ba/attachment.html From info at dnastudios.it Thu Apr 19 07:11:07 2007 From: info at dnastudios.it (DNA Studios s.r.l.) Date: Thu, 19 Apr 2007 16:11:07 +0200 Subject: [Live-devel] about openRTP In-Reply-To: <61042.54884.qm@web51101.mail.re2.yahoo.com> References: <61042.54884.qm@web51101.mail.re2.yahoo.com> Message-ID: <4627787B.6080606@dnastudios.it> hong liu ha scritto: > Then I used the command of "openRTP -v -4 -w 176 -h 144 -f 30 > rtsp://192.168.0.1/test.mp4 > test_video.mp4", and then I opened > test_video.mp4 with vlc, with nothing playing back. I also used > quicktime player to open it. It can be played back but there are some > problems in picture reconstruction and there is audio in between. What > is wrong with it. QuickTime only play h264 baseline profile, probably your video is encoded in main or hight profile. http://en.wikipedia.org/wiki/QuickTime ------------------------- Nicola From finlayson at live555.com Thu Apr 19 07:25:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Apr 2007 07:25:31 -0700 Subject: [Live-devel] about openRTP In-Reply-To: <61042.54884.qm@web51101.mail.re2.yahoo.com> References: <61042.54884.qm@web51101.mail.re2.yahoo.com> Message-ID: >First I used the command of "openRTP rtsp://192.168.0.1/test.mp4", >and then I got one audio file named audio-MPEG4-GENERIC-2 and one >video file named video-h264-1. I tried to open video-h264-1 with vlc >or mplayer, and all tries failed. I don't know what format this file >is. Is it h264 elementary stream file Yes, of course. The file name describes the contents of the stream. Unfortunaately, I know of no media player that can play the file in this format. >Then I used the command of "openRTP -v -4 -w 176 -h 144 -f 30 >rtsp://192.168.0.1/test.mp4 > test_video.mp4", and then I opened >test_video.mp4 with vlc, with nothing playing back. I also used >quicktime player to open it. It can be played back but there are >some problems in picture reconstruction and there is audio in >between. What is wrong with it. I don't know, but if you got audio, you must not have used the "-v" option, because that option causes only the video stream to be recorded. Also, you need to be certain that the width, height and framerate parameters that you gave are exactly those of the stream that you are trying to record, otherwise video will not play back correctly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From l1436636 at yahoo.com Thu Apr 19 07:46:49 2007 From: l1436636 at yahoo.com (hong liu) Date: Thu, 19 Apr 2007 07:46:49 -0700 (PDT) Subject: [Live-devel] about live555MediaServer Message-ID: <749426.50536.qm@web51109.mail.re2.yahoo.com> Now I want to stream h264 video coded file (elementary stream) and mp4 file including h264 video file. I found live555MediaServer is not able to do it. Is that true? If not, please advise me how to do it. Thank you in advance! Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/4e56c9aa/attachment.html From david at embedded-sol.com Thu Apr 19 08:11:19 2007 From: david at embedded-sol.com (David Ohayon) Date: Thu, 19 Apr 2007 18:11:19 +0300 Subject: [Live-devel] problem when using Ethernet over USB (RNDIS) for streaming Message-ID: <007401c78295$032bab40$ef00000a@david10> Hello, Thanks for the answer. I have checked if multicast packets transmitted by the device are visible on the PC running the viewer using Ethereal network protocol analyzer. The packets are visible. I also noticed that the self address of the streamer is determined by transmitting a multicast packet and when receiving it, extracting the sender address from it. This part works OK (I am aware of the WINCE multicast bug and its workaround, so I forced a 'correct' multicast address). I compared the packets captured when the RNDIS connection was active (the connection that does not work) to those captured when the ordinary Ethernet connection was active but could not see something that looked significant to me. A screen capture of the Ethereal window (jpg) and the capture files (*.cap - helpful if Ethereal is installed) can be found here: IP addresses when RNDIS is in use: 100.0.0.130 - the streaming device - running windows CE 5.0 100.0.0.4 - The viewing device - running windows XP service pack 2 http://www.embedded-sol.com/Rndis/rndis.jpg http://www.embedded-sol.com/Rndis/rndis3.cap http://www.embedded-sol.com/Rndis/ethernet1.cap Thanks, David Ohayon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/26f2989b/attachment.html From info at dnastudios.it Thu Apr 19 08:26:48 2007 From: info at dnastudios.it (DNA Studios s.r.l.) Date: Thu, 19 Apr 2007 17:26:48 +0200 Subject: [Live-devel] about live555MediaServer In-Reply-To: <749426.50536.qm@web51109.mail.re2.yahoo.com> References: <749426.50536.qm@web51109.mail.re2.yahoo.com> Message-ID: <46278A38.5040606@dnastudios.it> hong liu ha scritto: > Now I want to stream h264 video coded file (elementary stream) and mp4 > file including h264 video file. I found live555MediaServer is not able > to do it. Is that true? If not, please advise me how to do it. Thank > you in advance! You can use Darwin Streaming Server, but does not exist a player in the world able to seek this rtsp source......very strange but really. You can only play (with mplayer or vlc) from start to end but you can't move in the movie...the seeking operations make a crash or video not resyncronize well; all communities know this problem (videolan, mplayer, here, apple etc. etc.) but unfortunately at this moment seems that not there is a solution. The only way is to encode your video in baseline profile and play it with QT (obviously with Darwin as server). Bye. ---------------------- Nicola From l1436636 at yahoo.com Thu Apr 19 08:55:48 2007 From: l1436636 at yahoo.com (hong liu) Date: Thu, 19 Apr 2007 08:55:48 -0700 (PDT) Subject: [Live-devel] about live555MediaServer Message-ID: <233438.57539.qm@web51102.mail.re2.yahoo.com> Thank you Nicola! If I want to add the function that live555MediaServer is used to stream h264 elementary stream, how much effort I should make on modification of the souce code of live555MediaServer? Where, ... The openRTP is able to receive mp4 files and parse h264 video streams. Is there any way to enable live555MediaServer to stream mp4 or h264 elementary stream? Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/cd46aa30/attachment-0001.html From l1436636 at yahoo.com Thu Apr 19 09:11:39 2007 From: l1436636 at yahoo.com (hong liu) Date: Thu, 19 Apr 2007 09:11:39 -0700 (PDT) Subject: [Live-devel] about openRTP Message-ID: <66338.20046.qm@web51101.mail.re2.yahoo.com> >>First I used the command of "openRTP rtsp://192.168.0.1/test.mp4", >>and then I got one audio file named audio-MPEG4-GENERIC-2 and one >>video file named video-h264-1. I tried to open video-h264-1 with vlc >>or mplayer, and all tries failed. I don't know what format this file >>is. Is it h264 elementary stream file >Yes, of course. The file name describes the contents of the stream. >Unfortunaately, I know of no media player that can play the file in >this format. What is content of these audio and video files? for example, the test.mp4 contains a h.264 video coded file and mpeg4 audio file. Is video-h264-1 the original h.264 video coded file if there is no packet loss during transmission period? Now I want to record the h264 video stream in the test.mp4 into a file. would you advise me how to do it? >>Then I used the command of "openRTP -v -4 -w 176 -h 144 -f 30 >>rtsp://192.168.0.1/test.mp4 > test_video.mp4", and then I opened >>test_video.mp4 with vlc, with nothing playing back. I also used >>quicktime player to open it. It can be played back but there are >>some problems in picture reconstruction and there is audio in >>between. What is wrong with it. >I don't know, but if you got audio, you must not have used the "-v" >option, because that option causes only the video stream to be >recorded. >Also, you need to be certain that the width, height and framerate >parameters that you gave are exactly those of the stream that you are trying to >record, otherwise video will not play back correctly. Is there any difference for openRTP in recording video stream between the video only mp4 file and the video audio interleaved mp4 file? Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/3d044577/attachment.html From info at dnastudios.it Thu Apr 19 10:14:44 2007 From: info at dnastudios.it (DNA STUDIOS s.r.l.) Date: Thu, 19 Apr 2007 19:14:44 +0200 Subject: [Live-devel] about live555MediaServer In-Reply-To: <233438.57539.qm@web51102.mail.re2.yahoo.com> References: <233438.57539.qm@web51102.mail.re2.yahoo.com> Message-ID: <4627A384.4050902@dnastudios.it> hong liu ha scritto: > Thank you Nicola! > > If I want to add the function that live555MediaServer is used to stream > h264 elementary stream, how much effort I should make on modification of > the souce code of live555MediaServer? Where, ... > > The openRTP is able to receive mp4 files and parse h264 video streams. > Is there any way to enable live555MediaServer to stream mp4 or h264 > elementary stream? Unfortunately I don't know, I am not a software engineer, but if you succeed to implement this please tell me ;) Sure Ross know if this is possible and the way to... ------------- Nicola From finlayson at live555.com Thu Apr 19 12:26:48 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Apr 2007 12:26:48 -0700 Subject: [Live-devel] www.live555.com/mplayer In-Reply-To: References: Message-ID: Carl Eugen, Thanks for the note. I have updated our web page now. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Apr 19 12:31:33 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Apr 2007 12:31:33 -0700 Subject: [Live-devel] about live555MediaServer In-Reply-To: <233438.57539.qm@web51102.mail.re2.yahoo.com> References: <233438.57539.qm@web51102.mail.re2.yahoo.com> Message-ID: >The openRTP is able to receive mp4 files and parse h264 video >streams. Is there any way to enable live555MediaServer to stream mp4 >or h264 elementary stream? The server can already stream MPEG-4 Video Elementary Stream files. These must have file extension ".m4e". There is currently no support for streaming H.264 Video Elementary Stream files. See -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/e4f75817/attachment.html From rruthe02 at harris.com Thu Apr 19 12:48:32 2007 From: rruthe02 at harris.com (Rutherford, Robert) Date: Thu, 19 Apr 2007 15:48:32 -0400 Subject: [Live-devel] Segfault in FileSink while indexing MPEG2-TS Message-ID: <505F93C737C4B647A0007D96439B71770137E14B@mlbe2k7.cs.myharris.net> I am working to integrate the MPEG2-TS file indexer in to an existing application by basically using the same method as MPEG2TransportStreamIndexer.cpp within a function. However, the application crashes with a segmentation fault after writing 880-924 bytes or so of the index file (from a transport stream of approximately 180 MB). When I compile and run MPEG2TransportStreamIndexer as a stand-alone binary it works correctly on the same MPEG file. I need to use it within the application in order to better catch error values and prevent unneeded system calls. Has anyone else seen this problem, or is there a known issue in this release? Using a back trace from GDB is appears that the problem lies in FileSink::addData(). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/233de9fe/attachment.html From dweber at robotics.net Thu Apr 19 13:15:25 2007 From: dweber at robotics.net (Dan Weber) Date: Thu, 19 Apr 2007 16:15:25 -0400 Subject: [Live-devel] Alternate Sending/Receiving Ports Message-ID: <20070419201525.GA30561@Barney.robotics.net> Hi there, Is there anyway I can use Groupsock to send to a given port and receive on another? Thanks, Dan From chas.bryant at gmail.com Thu Apr 19 13:21:17 2007 From: chas.bryant at gmail.com (Chuck Bryant) Date: Thu, 19 Apr 2007 15:21:17 -0500 Subject: [Live-devel] Amino trickplay with live555 Message-ID: I am using an Amino 110H STB to stream the live555 feed. I'm using live555MediaServer and basically the FF or REW causes the screen to pause, and then it pixelates bad when you hit Play to resume the movie at that point. I know it must be something quirky with the movie content. I've seen on the groups where others have had this issue but I've never really seen what the final answer was. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/f6df4f99/attachment.html From finlayson at live555.com Thu Apr 19 15:30:30 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Apr 2007 15:30:30 -0700 Subject: [Live-devel] Alternate Sending/Receiving Ports In-Reply-To: <20070419201525.GA30561@Barney.robotics.net> References: <20070419201525.GA30561@Barney.robotics.net> Message-ID: >Is there anyway I can use Groupsock to send to a given port and >receive on another? Yes. First create it, specifying the port to receive on, and then change the port to send to using "Groupsock::changeDestinationParameters()". (See examples in the code.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Apr 19 15:38:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Apr 2007 15:38:11 -0700 Subject: [Live-devel] Segfault in FileSink while indexing MPEG2-TS In-Reply-To: <505F93C737C4B647A0007D96439B71770137E14B@mlbe2k7.cs.myharris.net> References: <505F93C737C4B647A0007D96439B71770137E14B@mlbe2k7.cs.myharris.net> Message-ID: >I am working to integrate the MPEG2-TS file indexer in to an >existing application by basically using the same method as >MPEG2TransportStreamIndexer.cpp within a function. However, the >application crashes with a segmentation fault after writing 880-924 >bytes or so of the index file (from a transport stream of >approximately 180 MB). When I compile and run >MPEG2TransportStreamIndexer as a stand-alone binary it works >correctly on the same MPEG file. I need to use it within the >application in order to better catch error values and prevent >unneeded system calls. Has anyone else seen this problem, or is >there a known issue in this release? No, there's no known problem. However, because the indexing code works OK in the supplied "MPEG2TransportStreamIndexer" application, but not when you modify it, you should be able to track down the problem without too much difficulty, I hope. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/d03fde50/attachment.html From zhouh31415 at 163.com Fri Apr 20 00:15:44 2007 From: zhouh31415 at 163.com (=?GBK?B?1ty66w==?=) Date: Fri, 20 Apr 2007 15:15:44 +0800 (CST) Subject: [Live-devel] About groupsock Message-ID: <7936279.1470721177053344249.JavaMail.root@bj163app33.163.com> Hi,all: I have a problem about groupsock when I run live lib on my embeded linux system. The program work fine until, recently, I run PPPoE on my embeded linux. The program print : "Unable to determine our source address: This computer has an invalid IP address : 0x0" Then, I found the print coming from GroupsockHelper.cpp and Groupsock.cpp. I don't know what's wrong with the program because there's no problem when I run Groupsock without PPPoE. And the system can also work with running PPPoE and unicast, but the printing ---- able to determine our source address: This computer has an invalid IP address : 0x0" ---- is still exist. When I run PPPoE and Groupsock, the video transport program shut down and print: "00:00:11 Groupsock(10:239.255.42.42,1234,7): failed to join group : setsockopt( IP_ADDR_MEMBERSHIP) error : No such device. Could you give me some suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070420/75ec65dc/attachment-0001.html From finlayson at live555.com Fri Apr 20 00:22:44 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2007 00:22:44 -0700 Subject: [Live-devel] About groupsock In-Reply-To: <7936279.1470721177053344249.JavaMail.root@bj163app33.163.com> References: <7936279.1470721177053344249.JavaMail.root@bj163app33.163.com> Message-ID: > When I run PPPoE and Groupsock, the video transport program shut >down and print: > > "00:00:11 Groupsock(10:239.255.42.42,1234,7): failed to join >group : setsockopt( IP_ADDR_MEMBERSHIP) error : No such device. The problem is apparently that multicast is not configured (at least not properly) for your network device. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Apr 20 00:49:18 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2007 00:49:18 -0700 Subject: [Live-devel] Amino trickplay with live555 In-Reply-To: References: Message-ID: > >I am using an Amino 110H STB to stream the live555 feed. I'm using >live555MediaServer and basically the FF or REW causes the screen to >pause, and then it pixelates bad when you hit Play to resume the >movie at that point. I know it must be something quirky with the >movie content. I've seen on the groups where others have had this >issue but I've never really seen what the final answer was. From what I can tell (from testing with your demo movie), the problem is that - in the transition between normal and 'trick play' streaming - the streaming of your Transport Stream file is too bursty for the Amino STB to handle. (Note that this is not true for all Transport Stream files - just some.) For more on this issue, see -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070420/32b9acb7/attachment.html From igor at mir2.org Fri Apr 20 04:03:18 2007 From: igor at mir2.org (Igor Bukanov) Date: Fri, 20 Apr 2007 13:03:18 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: <461B9639.7050907@crystalballinc.com> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> Message-ID: <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> On 10/04/07, Vlad Seryakov wrote: > I may use it in the closed network environment where i do not > authenticate by user name only but using IP address and/or MAC address > in addition. I faced the same problem where the server should reject clients based on the camera url-ip address. The solution was to patch RTSPServer class to add to it the following function: virtual Boolean checkClientAccess(int clientSocket, char const* urlSuffix); The default implementation returns true meaning that there is no restrictions on cleints. A subclass can override it to return false under some conditions. In that case RTSPServer replies with 401 Unauthorized without setting any digest headers. Here is the patch in full (its copy is attached as well): --- .pc/auth.patch/liveMedia/RTSPServer.cpp 2007-04-20 12:29:06.000000000 +0200 +++ liveMedia/RTSPServer.cpp 2007-04-20 12:29:50.922156590 +0200 @@ -75,16 +75,21 @@ void RTSPServer::addServerMediaSession(S if (sessionName == NULL) sessionName = ""; ServerMediaSession* existingSession = (ServerMediaSession*) (fServerMediaSessions->Add(sessionName, (void*)serverMediaSession)); removeServerMediaSession(existingSession); // if any } +Boolean RTSPServer::checkClientAccess(int clientSocket, char const* urlSuffix) +{ + return True; +} + ServerMediaSession* RTSPServer::lookupServerMediaSession(char const* streamName) { return (ServerMediaSession*)(fServerMediaSessions->Lookup(streamName)); } void RTSPServer::removeServerMediaSession(ServerMediaSession* serverMediaSession) { if (serverMediaSession == NULL) return; fServerMediaSessions->Remove(serverMediaSession->streamName()); @@ -457,17 +462,18 @@ void RTSPServer::RTSPClientSession::hand } void RTSPServer::RTSPClientSession ::handleCmd_DESCRIBE(char const* cseq, char const* urlSuffix, char const* fullRequestStr) { char* sdpDescription = NULL; char* rtspURL = NULL; do { - if (!authenticationOK("DESCRIBE", cseq, fullRequestStr)) break; + if (!authenticationOK("DESCRIBE", cseq, urlSuffix, fullRequestStr)) + break; // We should really check that the request contains an "Accept:" ##### // for "application/sdp", because that's what we're sending back ##### // Begin by looking up the "ServerMediaSession" object for the // specified "urlSuffix": ServerMediaSession* session = fOurServer.lookupServerMediaSession(urlSuffix); if (session == NULL) { @@ -1126,17 +1132,28 @@ static Boolean parseAuthorizationHeader( if (*fields == '\0' || *fields == '\r' || *fields == '\n') break; } delete[] parameter; delete[] value; return True; } Boolean RTSPServer::RTSPClientSession ::authenticationOK(char const* cmdName, char const* cseq, - char const* fullRequestStr) { + char const* urlSuffix, char const* fullRequestStr) { + + if (!fOurServer.checkClientAccess(fClientSocket, urlSuffix)) { + snprintf((char*)fResponseBuffer, sizeof fResponseBuffer, + "RTSP/1.0 401 Unauthorized\r\n" + "CSeq: %s\r\n" + "%s" + "\r\n", + cseq, dateHeader()); + return False; + } + // If we weren't set up with an authentication database, we're OK: if (fOurServer.fAuthDB == NULL) return True; char const* username = NULL; char const* realm = NULL; char const* nonce = NULL; char const* uri = NULL; char const* response = NULL; Boolean success = False; do { --- .pc/auth.patch/liveMedia/include/RTSPServer.hh 2007-04-20 12:29:14.000000000 +0200 +++ liveMedia/include/RTSPServer.hh 2007-04-20 12:29:55.810995282 +0200 @@ -70,16 +70,17 @@ public: // each client will get reclaimed (and the corresponding RTP stream(s) // torn down) if no RTSP commands - or RTCP "RR" packets - from the // client are received in at least "reclamationTestSeconds" seconds. static Boolean lookupByName(UsageEnvironment& env, char const* name, RTSPServer*& resultServer); void addServerMediaSession(ServerMediaSession* serverMediaSession); + virtual Boolean checkClientAccess(int clientSocket, char const* urlSuffix); virtual ServerMediaSession* lookupServerMediaSession(char const* streamName); void removeServerMediaSession(ServerMediaSession* serverMediaSession); void removeServerMediaSession(char const* streamName); char* rtspURL(ServerMediaSession const* serverMediaSession) const; // returns a "rtsp://" URL that could be used to access the // specified session (which must already have been added to // us using "addServerMediaSession()". @@ -135,17 +136,18 @@ private: char const* cseq); void handleCmd_PLAY(ServerMediaSubsession* subsession, char const* cseq, char const* fullRequestStr); void handleCmd_PAUSE(ServerMediaSubsession* subsession, char const* cseq); void handleCmd_GET_PARAMETER(ServerMediaSubsession* subsession, char const* cseq, char const* fullRequestStr); Boolean authenticationOK(char const* cmdName, char const* cseq, - char const* fullRequestStr); + char const* urlSuffix, + char const* fullRequestStr); void noteLiveness(); Boolean isMulticast() const { return fIsMulticast; } static void noteClientLiveness(RTSPClientSession* clientSession); static void livenessTimeoutTask(RTSPClientSession* clientSession); private: RTSPServer& fOurServer; unsigned fOurSessionId; -------------- next part -------------- A non-text attachment was scrubbed... Name: auth.patch Type: application/octet-stream Size: 4778 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070420/5d521a23/attachment.obj From ng at kth.se Fri Apr 20 04:11:50 2007 From: ng at kth.se (Nils Grundback) Date: Fri, 20 Apr 2007 13:11:50 +0200 Subject: [Live-devel] Amino trickplay with live555 In-Reply-To: References: Message-ID: <1177067510.11372.9.camel@nils-ubuntu> Hi On Fri, 2007-04-20 at 00:49 -0700, Ross Finlayson wrote: > > > > I am using an Amino 110H STB to stream the live555 feed. I'm using > > live555MediaServer and basically the FF or REW causes the screen to > > pause, and then it pixelates bad when you hit Play to resume the > > movie at that point. I know it must be something quirky with the > > movie content. I've seen on the groups where others have had this > > issue but I've never really seen what the final answer was. > > > From what I can tell (from testing with your demo movie), the problem > is that - in the transition between normal and 'trick play' streaming > - the streaming of your Transport Stream file is too bursty for the > Amino STB to handle. (Note that this is not true for all Transport > Stream files - just some.) I'm having the same problem with trick play. And it does not work with VLC as the client either. I'm using ffmpeg to create the ts-files and testProgs/MPEG2TransportStreamIndexer to create the tsx-files. Are there any other ways that is recommended? Does anyone have some information of what flags I should give to ffmpeg to make this work better? This is an example of how I create the ts-file: ffmpeg -i DVD-image.vob -y -t 00:02:00 -f mpegts -b 2000k -mbd 1 -an test.ts the inputfile (DVD-image.vob) comes from a PAL-dvd using vobcopy. Thanks /nils From l1436636 at yahoo.com Fri Apr 20 05:17:22 2007 From: l1436636 at yahoo.com (hong liu) Date: Fri, 20 Apr 2007 05:17:22 -0700 (PDT) Subject: [Live-devel] about live555MediaServer Message-ID: <928771.84618.qm@web51110.mail.re2.yahoo.com> I have one more question. Can the live555MediaServer multicast video? If not, is there any way to do it? Thank you so much for your help! Hong Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070420/cc1f6755/attachment.html From rruthe02 at harris.com Fri Apr 20 05:36:56 2007 From: rruthe02 at harris.com (Rutherford, Robert) Date: Fri, 20 Apr 2007 08:36:56 -0400 Subject: [Live-devel] Segfault in FileSink while indexing MPEG2-TS In-Reply-To: References: Message-ID: <505F93C737C4B647A0007D96439B71770137E14E@mlbe2k7.cs.myharris.net> Ross, It seems to be a problem with stack overflow. In our application we create each task with a stack size of 32k (which seems like plenty), however, when I increased the stack of the task that runs the indexer code to 128k, it works without error (testing on the ~180MB file). However, we need to be able to use this on a 2GB file, which we are unable to test at the time. I am worried that 128k may not be enough for a larger file. My best guess is that the stack overflow is caused by recursive function calls. Do you recall anything in the design that could cause several recursive function calls without returning? Date: Thu, 19 Apr 2007 15:38:11 -0700 From: Ross Finlayson Subject: Re: [Live-devel] Segfault in FileSink while indexing MPEG2-TS To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii" >I am working to integrate the MPEG2-TS file indexer in to an >existing application by basically using the same method as >MPEG2TransportStreamIndexer.cpp within a function. However, the >application crashes with a segmentation fault after writing 880-924 >bytes or so of the index file (from a transport stream of >approximately 180 MB). When I compile and run >MPEG2TransportStreamIndexer as a stand-alone binary it works >correctly on the same MPEG file. I need to use it within the >application in order to better catch error values and prevent >unneeded system calls. Has anyone else seen this problem, or is >there a known issue in this release? No, there's no known problem. However, because the indexing code works OK in the supplied "MPEG2TransportStreamIndexer" application, but not when you modify it, you should be able to track down the problem without too much difficulty, I hope. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070419/d03fd e50/attachment-0001.html From l1436636 at yahoo.com Fri Apr 20 07:35:18 2007 From: l1436636 at yahoo.com (hong liu) Date: Fri, 20 Apr 2007 07:35:18 -0700 (PDT) Subject: [Live-devel] about openRTSP Message-ID: <259276.38824.qm@web51106.mail.re2.yahoo.com> I intended to run openRTSP to receive only video data of a mpeg-2 transport stream from live555MediaServer , and this transport stream includes audio and video data. I got a video-MP2T-1 file and played it back with vlc. I found this file has audio data included. Then I tried it to receive both video and audio and there was no separate audio file generated except the same previous video file. If I want to get only video data for transport streams, how can I do it? In addition, I put a mp4 file including only h264 video data in Darwin streaming server and used openRTSP to get only video data. In the beginning, vlc couldn't playback the resulting video data. After I analyzed the byte stream of the saved video data, it missed the SPS and PPS NAL units. So I copy them from the original file into it and now it works for vlc. I don't know where I modify the source code so that it can save SPS and PPS NAL units as well. Thank you so much for your help! Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070420/8159f1f4/attachment.html From finlayson at live555.com Fri Apr 20 08:08:02 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2007 08:08:02 -0700 Subject: [Live-devel] about live555MediaServer In-Reply-To: <928771.84618.qm@web51110.mail.re2.yahoo.com> References: <928771.84618.qm@web51110.mail.re2.yahoo.com> Message-ID: >I have one more question. Can the live555MediaServer multicast video? No, that application streams via unicast only > If not, is there any way to do it? Use one of the "test*Streamer" demo applications, in the "testProgs" directory. See -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070420/0e2ee188/attachment.html From finlayson at live555.com Fri Apr 20 08:12:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2007 08:12:20 -0700 Subject: [Live-devel] about openRTSP In-Reply-To: <259276.38824.qm@web51106.mail.re2.yahoo.com> References: <259276.38824.qm@web51106.mail.re2.yahoo.com> Message-ID: >I intended to run openRTSP to receive only video data of a mpeg-2 >transport stream from live555MediaServer No, that won't work, because MPEG Transport Streams are streamed (in RTP) 'as is', with audio and video multiplexed together. >If I want to get only video data for transport streams, how can I do it? You can't, unless you demultiplex video from the received Transport Stream, *after* you receive it. (You would need to use something other than our software to do this.) > >In addition, I put a mp4 file including only h264 video data in >Darwin streaming server and used openRTSP to get only video data. In >the beginning, vlc couldn't playback the resulting video data. After >I analyzed the byte stream of the saved video data, it missed the >SPS and PPS NAL units. So I copy them from the original file into it >and now it works for vlc. I don't know where I modify the source >code so that it can save SPS and PPS NAL units as well. You would do this in "H264VideoFileSink.cpp". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Apr 20 08:14:51 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2007 08:14:51 -0700 Subject: [Live-devel] Amino trickplay with live555 In-Reply-To: <1177067510.11372.9.camel@nils-ubuntu> References: <1177067510.11372.9.camel@nils-ubuntu> Message-ID: >I'm having the same problem with trick play. And it does not work with >VLC as the client either. If you can't play the stream (without 'trick play') using VLC, then you have more serious problems, that you should address before you begin thinking about 'trick play'. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Apr 20 08:18:25 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2007 08:18:25 -0700 Subject: [Live-devel] Segfault in FileSink while indexing MPEG2-TS In-Reply-To: <505F93C737C4B647A0007D96439B71770137E14E@mlbe2k7.cs.myharris.net> References: <505F93C737C4B647A0007D96439B71770137E14E@mlbe2k7.cs.myharris.net> Message-ID: >It seems to be a problem with stack overflow. In our application we >create each task with a stack size of 32k (which seems like plenty), By "task", I hope you don't mean "thread", because if you do, then you may not have read (If you want to index more than one file in parallel, then the best way to do this is to spawn multiple copies of a single indexing application (e.g., "MPEG2TransportStreamIndexer"), not using multiple threads within a single application.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070420/0a903fe3/attachment.html From finlayson at live555.com Fri Apr 20 11:34:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2007 11:34:07 -0700 Subject: [Live-devel] RTSP server extending In-Reply-To: <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> Message-ID: >On 10/04/07, Vlad Seryakov wrote: >>I may use it in the closed network environment where i do not >>authenticate by user name only but using IP address and/or MAC address >>in addition. > >I faced the same problem where the server should reject clients based >on the camera url-ip address. The solution was to patch RTSPServer >class to add to it the following function: > > virtual Boolean checkClientAccess(int clientSocket, char const* urlSuffix); > >The default implementation returns true meaning that there is no >restrictions on cleints. A subclass can override it to return false >under some conditions. In that case RTSPServer replies with 401 >Unauthorized without setting any digest headers. Thanks for the patch. I have now added your patch to the code (although I changed the name of your function to "specialClientAccessCheck"), and have included it in a new release (2007.04.20) of the "LIVE555 Streaming Media" software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From cehoyos at rainbow.studorg.tuwien.ac.at Fri Apr 20 17:17:54 2007 From: cehoyos at rainbow.studorg.tuwien.ac.at (Carl Eugen Hoyos) Date: Sat, 21 Apr 2007 02:17:54 +0200 (CEST) Subject: [Live-devel] Starttime patch In-Reply-To: References: Message-ID: Hi Ross! I'm working on a seeking patch for mplayer. Are you planning to include the starttime patch from vlc? http://trac.videolan.org/vlc/browser/trunk/extras/contrib/src/Patches/live-starttime.patch Or do you think it's not correct? Thank you, Carl Eugen From finlayson at live555.com Fri Apr 20 17:27:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Apr 2007 17:27:06 -0700 Subject: [Live-devel] Starttime patch In-Reply-To: References: Message-ID: >Hi Ross! > >I'm working on a seeking patch for mplayer. >Are you planning to include the starttime patch from vlc? The VLC developers (specifically Jean-Paul Saman) tell me that they are still working on their updated version of VLC (which will use this, and perhaps other, patches to the LIVE555 code to better implement client 'trick play' operations). My understanding is that when they are ready to release this new version of VLC, they will also send me their patches, for inclusion in the "LIVE555 Streaming Media" libraries. So, I'm planning to wait on word from the VLC developers, before I integrate their patches. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From luis.figueiredo at tagus.ist.utl.pt Sat Apr 21 07:38:24 2007 From: luis.figueiredo at tagus.ist.utl.pt (=?ISO-8859-1?Q?Lu=EDs_Figueiredo?=) Date: Sat, 21 Apr 2007 15:38:24 +0100 Subject: [Live-devel] Amino trickplay with live555 In-Reply-To: References: <1177067510.11372.9.camel@nils-ubuntu> Message-ID: <462A21E0.9030304@tagus.ist.utl.pt> I'm having the same problem with trick play in amino. I tested with a testMPEG2TransportStreamTrickPlay and it's work fine. What is the problem? The buffer is not the problem because de testMPEG2TransportStreamTrickPlay work very well. Thanks Lu?s Figueiredo Ross Finlayson wrote: >> I'm having the same problem with trick play. And it does not work with >> VLC as the client either. >> > > If you can't play the stream (without 'trick play') using VLC, then > you have more serious problems, that you should address before you > begin thinking about 'trick play'. > From finlayson at live555.com Sat Apr 21 08:38:42 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Apr 2007 08:38:42 -0700 Subject: [Live-devel] Amino trickplay with live555 In-Reply-To: <462A21E0.9030304@tagus.ist.utl.pt> References: <1177067510.11372.9.camel@nils-ubuntu> <462A21E0.9030304@tagus.ist.utl.pt> Message-ID: >I'm having the same problem with trick play in amino. I tested with a >testMPEG2TransportStreamTrickPlay and it's work fine. > >What is the problem? The buffer is not the problem because de >testMPEG2TransportStreamTrickPlay work very well. As I've said before, we *suspect* that the problem is that the Amino STB is not properly handling the *transition* between the normal play stream, and the 'trick play' stream - perhaps due to excessive burstiness. (Note that this is not true for all Transport Stream files, just some.) However, since I have no way of debugging the Amino STB, I have no way of knowing exactly why it's failing. A reminder, once again, that Live Networks, Inc. has no affiliation with Amino Technologies; we just happen to have an "AmiNet 103" sitting around our lab. I strongly urge someone from Amino Technologies (or, failing that, someone who has the ability to debug their hardware) to report *exactly* why their STBs are not handling the transition between normal play and 'trick play' - using our server - for some Transport Stream files. Until that time, I'm unlikely to be saying much more on this topic. Alternatively, if people know of other set-top box hardware that can properly play MPEG Transport Streams - with 'trick play' - from our (unmodified) server software, then please let us know, so we can publicize them (as an alternative to Amino) as possible RTSP clients. Finally, a reminder that VLC (as a RTSP client) will apparently be supporting 'trick play' operations Real Soon Now. (We're all staying tuned for an announcement from the VLC developers.) From ismail at pardus.org.tr Sat Apr 21 12:50:01 2007 From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=) Date: Sat, 21 Apr 2007 22:50:01 +0300 Subject: [Live-devel] Locale related problem in MediaSession.cpp Message-ID: <200704212250.05251.ismail@pardus.org.tr> Hi all, MediaSession.cpp (from live-2007.02.24) starting line 941 : for (char* p = codecName; *p != '\0'; ++p) { *p = toupper(*p); } This results in problem with Turkish and similar locales where toupper('i') is not I but I-with-a-dot above (?) . I attached a simple patch to fix the problem. Without this patch VLC can't play some audio streams because codec name is passed as audio/MPEG4-GENERiC (notice lowercase i) instead of audio/MPEG4-GENERIC . Best Regards, ismail -- Life is a game, and if you aren't in it to win, what the heck are you still doing here? -- Linus Torvalds (talking about open source development) -------------- next part -------------- A non-text attachment was scrubbed... Name: locale.patch Type: text/x-diff Size: 991 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070421/accbec0e/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.live555.com/pipermail/live-devel/attachments/20070421/accbec0e/attachment-0003.bin From finlayson at live555.com Sat Apr 21 14:28:35 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Apr 2007 14:28:35 -0700 Subject: [Live-devel] Locale related problem in MediaSession.cpp In-Reply-To: <200704212250.05251.ismail@pardus.org.tr> References: <200704212250.05251.ismail@pardus.org.tr> Message-ID: Ismail (or is that ismail :-) Thanks for the report. This will be fixed in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ismail at pardus.org.tr Sat Apr 21 14:46:42 2007 From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=) Date: Sun, 22 Apr 2007 00:46:42 +0300 Subject: [Live-devel] Locale related problem in MediaSession.cpp In-Reply-To: References: <200704212250.05251.ismail@pardus.org.tr> Message-ID: <200704220046.49045.ismail@pardus.org.tr> On Sunday 22 April 2007 00:28:35 Ross Finlayson wrote: > Ismail (or is that ismail :-) its ?smail but for Unicode-safeness I use Ismail :-) > Thanks for the report. This will be fixed in the next release of the > software. Thanks! -- Life is a game, and if you aren't in it to win, what the heck are you still doing here? -- Linus Torvalds (talking about open source development) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.live555.com/pipermail/live-devel/attachments/20070421/c7861163/attachment.bin From finlayson at live555.com Sat Apr 21 16:42:46 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Apr 2007 16:42:46 -0700 Subject: [Live-devel] Locale related problem in MediaSession.cpp In-Reply-To: <200704220046.49045.ismail@pardus.org.tr> References: <200704212250.05251.ismail@pardus.org.tr> <200704220046.49045.ismail@pardus.org.tr> Message-ID: > > Ismail (or is that ismail :-) > >its I?smail but for Unicode-safeness I use Ismail :-) I remember, when I visited Turkey in August 1999 (to watch a solar eclipse), I had a lot of difficulty typing on the computers in local 'cyber cafes'. The two variants of the letter "i" caused me lots of problems :-) Ross. From berglund at math.gatech.edu Sat Apr 21 19:17:39 2007 From: berglund at math.gatech.edu (Nathanael Berglund) Date: Sat, 21 Apr 2007 22:17:39 -0400 (EDT) Subject: [Live-devel] Cryptic error message when compiling with Bloodshed DevC++ Message-ID: I'm using the free development software Bloodshed DevC++ for doing my programming, and I've been trying to get it to compile the source code for LIVE555, but when I start trying to compile each directory ('BasicUsageEnvironment', 'groupsock', 'liveMedia', and 'UsageEnvironment') I get the rather cryptic error message: in BasicUsageEnvironment.mak [Build Error] No rule to make target `BasicUsageEnvironment0.obj', needed by `libBasicUsageEnvironment.lib'. Stop. I'm not familiar with the syntax of makefiles, and this error is greek to me! Does anyone know what exactly this error means? Or what I may be doing wrong? -- Nate From ilya77 at gmail.com Sun Apr 22 09:09:33 2007 From: ilya77 at gmail.com (ilya77 at gmail.com) Date: Sun, 22 Apr 2007 19:09:33 +0300 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss Message-ID: Hi All, We've tried to use Live555 media server (win32) with various max packet size configurations (we've compiled the server with each change) with an MPEG2 transport stream we've received from a customer over a WAN, and while the same configurations worked flawlessly in a LAN environment, sniffing the RTP stream delivered over a WAN (over ATM + NAT router) with ethereal discovered a lot of lost packets (and as a result - degradation in picture quality, artefacts and smearing where motion occurred). We've tried different files with various bitrates, so I am pretty much sure bandwidth is not the issue. The RTP transport was delivered over TCP, and we've used VLC as the client application. We've tried the default max packet size, and the following: 1400, 1300, 1350, 1340, 1330 bytes per packet (not including overhead). Interesting is that the stream would not play when max packet size was set below 1330. Could anyone refer me to any resource which would help me to solve the problem? Searching google didn't produce any helpful results, and since we are not experts on RTSP/RTP/MPEG2-TS, digging into the source code didn't help much either... Many thanks, Ilya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070422/5ec75f31/attachment.html From finlayson at live555.com Sun Apr 22 10:45:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Apr 2007 10:45:14 -0700 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: References: Message-ID: >and while the same configurations worked flawlessly in a LAN >environment, sniffing the RTP stream delivered over a WAN (over ATM >+ NAT router) with ethereal discovered a lot of lost packets (and as >a result - degradation in picture quality, artefacts and smearing >where motion occurred). >We've tried different files with various bitrates, so I am pretty >much sure bandwidth is not the issue. Actually, I'm pretty sure that bandwidth *is* the issue. If you have no packet loss when streaming over a LAN, but get packet loss when streaming over a WAN, then the problem is almost certainly that your stream is too high-bandwidth for your WAN (and/or perhaps its routers). I.e., you have a network problem, not a problem with our software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From zhouh31415 at 163.com Sun Apr 22 18:32:22 2007 From: zhouh31415 at 163.com (=?GBK?B?1ty66w==?=) Date: Mon, 23 Apr 2007 09:32:22 +0800 (CST) Subject: [Live-devel] Then , how to config? Message-ID: <28643165.2635651177291942085.JavaMail.root@bj163app44.163.com> > When I run PPPoE and Groupsock, the video transport program shut >down and print: > > "00:00:11 Groupsock(10:239.255.42.42,1234,7): failed to join >group : setsockopt( IP_ADDR_MEMBERSHIP) error : No such device. The problem is apparently that multicast is not configured (at least not properly) for your network device. Yes, I do nothing but run the program below, just like your testprog: Groupsock rtpGroupsock(*env, destinationAddress, rtpPort,ttl); Groupsock rctpGroupsock(*env, destinationAddress, rtcpPort,ttl); How to config my network device? Is it in my linux system? Maybe I should understand multicast deeply. Thanks!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070422/9bf92591/attachment.html From ng at kth.se Mon Apr 23 02:57:46 2007 From: ng at kth.se (Nils Grundback) Date: Mon, 23 Apr 2007 11:57:46 +0200 Subject: [Live-devel] typo in testOnDemandRTSPServer.cpp, does not read TS-index file Message-ID: <1177322266.14146.6.camel@nils-ubuntu> Hi There is a small typo in the file testOnDemandRTSPServer.cpp. It specifies the index file for the mpeg2TransportStreamTest as test.ts instead of test.tsx. here is a small patch (also attached): --- testProgs/testOnDemandRTSPServer_org.cpp 2007-04-23 11:33:17.000000000 +0200 +++ testProgs/testOnDemandRTSPServer.cpp 2007-04-23 11:33:44.000000000 +0200 @@ -195,7 +195,7 @@ { char const* streamName = "mpeg2TransportStreamTest"; char const* inputFileName = "test.ts"; - char const* indexFileName = "test.ts"; + char const* indexFileName = "test.tsx"; ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); /nils -------------- next part -------------- A non-text attachment was scrubbed... Name: read_tsx_file.patch Type: text/x-patch Size: 503 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070423/f2314e74/attachment.bin From opera at kth.se Mon Apr 23 02:58:23 2007 From: opera at kth.se (=?ISO-8859-1?Q?Gustaf_R=E4ntil=E4?=) Date: Mon, 23 Apr 2007 11:58:23 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> Message-ID: <462C833F.3020302@kth.se> Ross Finlayson wrote: >> On 10/04/07, Vlad Seryakov wrote: >> >>> I may use it in the closed network environment where i do not >>> authenticate by user name only but using IP address and/or MAC address >>> in addition. >>> >> I faced the same problem where the server should reject clients based >> on the camera url-ip address. The solution was to patch RTSPServer >> class to add to it the following function: >> >> virtual Boolean checkClientAccess(int clientSocket, char const* urlSuffix); >> >> The default implementation returns true meaning that there is no >> restrictions on cleints. A subclass can override it to return false >> under some conditions. In that case RTSPServer replies with 401 >> Unauthorized without setting any digest headers. >> > > Thanks for the patch. > > I have now added your patch to the code (although I changed the name > of your function to "specialClientAccessCheck"), and have included it > in a new release (2007.04.20) of the "LIVE555 Streaming Media" > software. > The patch provided in this thread introduces control for authenticating a certain socket to a certain url suffix which is useful. I've made a similar patch, and I'm grateful that I can now remove half of it. The other half of mine remains.. What I'm missing in this patch is control to accept or deny incoming connections (before the RTSPClientSession object is created) based on the IP/port. The provided patch doesn't handle this, so a connection (and thereby an RTSPClientSession) is always created for all IP/port's, which might not be a desirable behavior. If there is interest for a patch which provides this, through another virtual function, let me know, and I'll send it in. Gustaf From mrnikhilagrawal at gmail.com Mon Apr 23 03:22:01 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Mon, 23 Apr 2007 15:52:01 +0530 Subject: [Live-devel] Regarding WAV streaming Message-ID: <733cde3e0704230322t4e08549cj5a85584eed12c5a5@mail.gmail.com> Hi, I was looking into Live555 Server code but didn't understood that how sink comes to know that this is the last frame to be sent and source has no more data. How does it maintains such counters? Please help me if anyone knows the logic behind it. Thanks and Regards, NIkhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070423/79f932d7/attachment-0001.html From finlayson at live555.com Mon Apr 23 05:53:47 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Apr 2007 05:53:47 -0700 Subject: [Live-devel] Regarding WAV streaming In-Reply-To: <733cde3e0704230322t4e08549cj5a85584eed12c5a5@mail.gmail.com> References: <733cde3e0704230322t4e08549cj5a85584eed12c5a5@mail.gmail.com> Message-ID: >I was looking into Live555 Server code but didn't understood that >how sink comes to know that this is the last frame to be sent and >source has no more data. This is done via the "afterFunc" parameter that you passed to "startPlaying()", when you called it. That function (parameter) gets called when the source runs out of data. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From l1436636 at yahoo.com Mon Apr 23 06:54:50 2007 From: l1436636 at yahoo.com (hong liu) Date: Mon, 23 Apr 2007 06:54:50 -0700 (PDT) Subject: [Live-devel] Windows compilation problem with Livemedia Message-ID: <42128.8250.qm@web51109.mail.re2.yahoo.com> I downloaded live.2007.04.20.tar.gz. My PC have installed Visual C++ 6.0. From the instructions posted in the web site, I first change the directory of Tools from "c:\Program Files\DevStudio\Vc" to "C:\Program Files\Microsoft Visual Studio\COMMON\Tools" in the variable of the "TOOLS32 =" line in the file "win32config". Then I ran genWindowsMakefiles in the DOS Command Prompt window and it said: Could Not Find C:\Temp\live\mediaServer\mediaServer.mak Could Not Find C:\Temp\live\mediaServer\Makefile I didn't find any mediaServer.mak in the package. Is it missed in the package? Hong Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070423/2b7dc70e/attachment.html From vlad at crystalballinc.com Mon Apr 23 07:23:50 2007 From: vlad at crystalballinc.com (Vlad Seryakov) Date: Mon, 23 Apr 2007 10:23:50 -0400 Subject: [Live-devel] RTSP server extending In-Reply-To: <462C833F.3020302@kth.se> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> Message-ID: <462CC176.1070400@crystalballinc.com> I would be interested > What I'm missing in this patch is control to accept or deny incoming > connections (before the RTSPClientSession object is created) based on > the IP/port. > The provided patch doesn't handle this, so a connection (and thereby an > RTSPClientSession) is always created for all IP/port's, which might not > be a desirable behavior. > > If there is interest for a patch which provides this, through another > virtual function, let me know, and I'll send it in. > > Gustaf > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From ilya77 at gmail.com Mon Apr 23 08:03:35 2007 From: ilya77 at gmail.com (ilya77 at gmail.com) Date: Mon, 23 Apr 2007 19:03:35 +0400 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: References: Message-ID: Hi Ross, Thank you for the reply, however, I must disagree. We have 5 MBit downstream / 1 MBit upstream link, and the problem appeared even with a 600 KBps file. We've monitored our internet gateway during the test, and there was no load on the link other than the streaming media. I should also add, that I have several year of experience with streaming media in general, and as far as I can tell - it is NOT bandwidth. What I do suspect is the size of the packets which come out of the server (which might be OK for LAN), which are just too big for some router along the way, and are either dropped, or getting fragmented. Any ideas? Thanks, Ilya On 4/22/07, Ross Finlayson wrote: > > >and while the same configurations worked flawlessly in a LAN > >environment, sniffing the RTP stream delivered over a WAN (over ATM > >+ NAT router) with ethereal discovered a lot of lost packets (and as > >a result - degradation in picture quality, artefacts and smearing > >where motion occurred). > >We've tried different files with various bitrates, so I am pretty > >much sure bandwidth is not the issue. > > Actually, I'm pretty sure that bandwidth *is* the issue. If you have > no packet loss when streaming over a LAN, but get packet loss when > streaming over a WAN, then the problem is almost certainly that your > stream is too high-bandwidth for your WAN (and/or perhaps its > routers). > > I.e., you have a network problem, not a problem with our software. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070423/55497b30/attachment.html From glen at lincor.com Mon Apr 23 08:24:34 2007 From: glen at lincor.com (Glen Gray) Date: Mon, 23 Apr 2007 16:24:34 +0100 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: References: Message-ID: <462CCFB2.8070703@lincor.com> May or may not be relevant, but we had problems before with packet sizes and MPEG2 transport streamns that where not a multiple of 188, so we settled on 1316 (188*7) packet size. This was with a different server setup but with VLC using liveMedia as the rtsp client. ilya77 at gmail.com wrote: > Hi All, > > We've tried to use Live555 media server (win32) with various max packet > size configurations (we've compiled the server with each change) with an > MPEG2 transport stream we've received from a customer over a WAN, and > while the same configurations worked flawlessly in a LAN environment, > sniffing the RTP stream delivered over a WAN (over ATM + NAT router) > with ethereal discovered a lot of lost packets (and as a result - > degradation in picture quality, artefacts and smearing where motion > occurred). > We've tried different files with various bitrates, so I am pretty much > sure bandwidth is not the issue. > The RTP transport was delivered over TCP, and we've used VLC as the > client application. > We've tried the default max packet size, and the following: 1400, 1300, > 1350, 1340, 1330 bytes per packet (not including overhead). Interesting > is that the stream would not play when max packet size was set below 1330. > > Could anyone refer me to any resource which would help me to solve the > problem? Searching google didn't produce any helpful results, and since > we are not experts on RTSP/RTP/MPEG2-TS, digging into the source code > didn't help much either... > > Many thanks, > Ilya > > > ------------------------------------------------------------------------ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -- Glen Gray Digital Depot, Thomas Street Senior Software Engineer Dublin 8, Ireland Lincor Solutions Ltd. Ph: +353 (0) 1 4893682 From finlayson at live555.com Mon Apr 23 16:19:24 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Apr 2007 16:19:24 -0700 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: <462CCFB2.8070703@lincor.com> References: <462CCFB2.8070703@lincor.com> Message-ID: >May or may not be relevant, but we had problems before with packet sizes >and MPEG2 transport streamns that where not a multiple of 188, so we >settled on 1316 (188*7) packet size. Our software already streams MPEG Transport Streams using that size packet (+ 12 bytes for a RTP header, if RTP is being used). I doubt that your problem has anything to do with packet sizes (or, for that matter, our software). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ilya77 at gmail.com Mon Apr 23 17:38:04 2007 From: ilya77 at gmail.com (ilya77 at gmail.com) Date: Tue, 24 Apr 2007 04:38:04 +0400 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: References: <462CCFB2.8070703@lincor.com> Message-ID: Hi Ross, >From my experience, dividing the problem into "your" software and "our" network doesn't benefit anyone, either in commercial or open source environment. I am willing to work with anyone who wants to help in order to solve our problem, and maybe improve the software (through providing a testing environment which produces the problem).I do not imply that the source of the problem is software, however, from our observations it's hard to conclude that the WAN is to blame (although it's the first impression). I am trying to make the server to send packets which would go through the WAN without problems. Please be assured - we have enough bandwidth to send the data. And also - reducing max packet size DID have some impact on the lost packets vs received packets ratio, not perfect, but it DID improve the sittuation to some degree. Thank you, Ilya On 4/24/07, Ross Finlayson wrote: > > >May or may not be relevant, but we had problems before with packet sizes > >and MPEG2 transport streamns that where not a multiple of 188, so we > >settled on 1316 (188*7) packet size. > > Our software already streams MPEG Transport Streams using that size > packet (+ 12 bytes for a RTP header, if RTP is being used). > > I doubt that your problem has anything to do with packet sizes (or, > for that matter, our software). > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070423/a6503a99/attachment.html From finlayson at live555.com Mon Apr 23 17:42:46 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Apr 2007 17:42:46 -0700 Subject: [Live-devel] RTSP server extending In-Reply-To: <462C833F.3020302@kth.se> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> Message-ID: >The patch provided in this thread introduces control for authenticating >a certain socket to a certain url suffix which is useful. I've made a >similar patch, and I'm grateful that I can now remove half of it. The >other half of mine remains.. > >What I'm missing in this patch is control to accept or deny incoming >connections (before the RTSPClientSession object is created) based on >the IP/port. OK, in the latest version of the software (2007.04.24, released today), the signature of the "specialClientAccessCheck()" virtual function has been chanegd to: virtual Boolean specialClientAccessCheck(int clientSocket, struct sockaddr_in& clientAddr, char const* urlSuffix); Note the new "clientAddr" (it's a sockaddr_in, so it has the client's port as well as its IP address). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From igor at mir2.org Tue Apr 24 01:36:03 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 24 Apr 2007 10:36:03 +0200 Subject: [Live-devel] Fix for DEBUG compilation of 2007-04-24 Message-ID: <7dee4710704240136s6f66b36bqa58c2ad0250c7397@mail.gmail.com> Hi! The latest release does not compile with DEBUG defined: RTSPOverHTTPServer.cpp:224:21: missing terminating " character The attached (also inlined bellow) fixes this. Regards, Igor --- .pc/2007_04_24_debug_fix.patch/liveMedia/RTSPOverHTTPServer.cpp 2007-04-24 02:34:48.000000000 +0200 +++ liveMedia/RTSPOverHTTPServer.cpp 2007-04-24 10:24:31.017858362 +0200 @@ -216,18 +216,19 @@ void RTSPOverHTTPServer::HTTPClientConne acceptStr, sizeof acceptStr, contentTypeStr, sizeof contentTypeStr) { #ifdef DEBUG fprintf(stderr, "parseRTSPRequestString() failed!\n"); #endif handleCmd_bad(cseq); } else { #ifdef DEBUG - fprintf(stderr, "parseRTSPRequestString() returned cmdName \"%s\", urlPreSuffix \"%s -\", urlSuffix \"%s\"\n", cmdName, urlPreSuffix, urlSuffix); + fprintf(stderr, "parseRTSPRequestString() returned " + "cmdName \"%s\", urlPreSuffix \"%s\", urlSuffix \"%s\"\n", + cmdName, urlPreSuffix, urlSuffix); #endif if (strcmp(cmdName, "OPTIONS") == 0) { handleCmd_OPTIONS(cseq); } else if (strcmp(cmdName, "DESCRIBE") == 0) { handleCmd_DESCRIBE(cseq, urlSuffix, (char const*)fRequestBuffer); } else if (strcmp(cmdName, "SETUP") == 0) { handleCmd_SETUP(cseq, urlPreSuffix, urlSuffix, (char const*)fRequestBuffer); } else if (strcmp(cmdName, "TEARDOWN") == 0 -------------- next part -------------- A non-text attachment was scrubbed... Name: 2007_04_24_debug_fix.patch Type: application/octet-stream Size: 1175 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070424/f26dfe20/attachment-0001.obj From igor at mir2.org Tue Apr 24 01:41:32 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 24 Apr 2007 10:41:32 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> Message-ID: <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> On 24/04/07, Ross Finlayson wrote: > OK, in the latest version of the software (2007.04.24, released > today), the signature of the "specialClientAccessCheck()" virtual > function has been chanegd to: > virtual Boolean specialClientAccessCheck(int clientSocket, > struct sockaddr_in& clientAddr, > char const* urlSuffix); > > Note the new "clientAddr" (it's a sockaddr_in, so it has the client's > port as well as its IP address). With the patch I submitted I missed that clientAddr is already available in RTSPServer and used getpeername to obtain it from clientSocket. The new signature saves this call. Nice! Regards, Igor > -- > > 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 igor at mir2.org Tue Apr 24 01:46:58 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 24 Apr 2007 10:46:58 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: <462C833F.3020302@kth.se> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> Message-ID: <7dee4710704240146o4b30af9aueb5101cc207107a6@mail.gmail.com> On 23/04/07, Gustaf R?ntil? wrote: > What I'm missing in this patch is control to accept or deny incoming > connections (before the RTSPClientSession object is created) based on > the IP/port. Is it a task for a firewall software to implement a generic block of a particular client without reading the RTSP packets it submits? Regards, Igor From igor at mir2.org Tue Apr 24 02:02:08 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 24 Apr 2007 11:02:08 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> Message-ID: <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> On 24/04/07, Igor Bukanov wrote: > On 24/04/07, Ross Finlayson wrote: > > OK, in the latest version of the software (2007.04.24, released > > today), the signature of the "specialClientAccessCheck()" virtual > > function has been chanegd to: > > virtual Boolean specialClientAccessCheck(int clientSocket, > > struct sockaddr_in& clientAddr, > > char const* urlSuffix); > > > > Note the new "clientAddr" (it's a sockaddr_in, so it has the client's > > port as well as its IP address). > > With the patch I submitted I missed that clientAddr is already > available in RTSPServer and used getpeername to obtain it from > clientSocket. The new signature saves this call. Nice! Actually there is problem here with sockaddr_in. It explicitly excludes sockaddr_in6. It would better just to use sockaddr to simplify IPV6 porting later. Regards, Igor From finlayson at live555.com Tue Apr 24 02:35:47 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2007 02:35:47 -0700 Subject: [Live-devel] RTSP server extending In-Reply-To: <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> Message-ID: >Actually there is problem here with sockaddr_in. It explicitly >excludes sockaddr_in6. It would better just to use sockaddr to >simplify IPV6 porting later. The actual parameter to the call is a "sockaddr_in", so that's what I used for the formal parameter. There are many many places in the code that are IPv4-specific, unfortunately. (The networking (groupsock) code will need to undergo a major restructuring before IPv6 could be supported...) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From opera at kth.se Tue Apr 24 04:08:42 2007 From: opera at kth.se (=?ISO-8859-1?Q?Gustaf_R=E4ntil=E4?=) Date: Tue, 24 Apr 2007 13:08:42 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> Message-ID: <462DE53A.7050301@kth.se> Ross Finlayson wrote: >> Actually there is problem here with sockaddr_in. It explicitly >> excludes sockaddr_in6. It would better just to use sockaddr to >> simplify IPV6 porting later. >> > > The actual parameter to the call is a "sockaddr_in", so that's what I > used for the formal parameter. > > There are many many places in the code that are IPv4-specific, > unfortunately. (The networking (groupsock) code will need to undergo > a major restructuring before IPv6 could be supported...) > The second patch merely fixes a part of what was missing, and it really makes no sense to try to solve it all with one function. Therefore I send in my solution as a patch (to the latest release). It extends the other patches from this thread in the following manner: Connections are controlled by a virtual function (accept/deny). It brings a file descriptor of the socket of the session that will be created as well as the address of the socket. When the connection for the session is lost (client disconnected), the same function is run again with the address parameter set to NULL. The user implementation can then (if needed off course), track sessions (with certain IP/port) and what resources they're accessing (see below). It has also shown to be good for debugging (what clients from what location is connecting/disconnecting). Definition: virtual Boolean sessionAccept(int clientSocket, const struct sockaddr* clientAddr); Note: The address is not necessary since you can get that information from the file descriptor through getsockname, but why not give it to the users who want it? And it is used to show that a session is disconnected (no use for yet another virtual function). Alternative implementation: The address is a "struct sockaddr" which is already exposed in the headers from the NetCommon.hh. If Ross (or anyone else) finds it more beautiful to use the NetAddress and Port classes, feel free to change this. But note that neither of these classes are very useful at the moment. They do not expose any comparison operators whatsoever, and I didn't want to go into that part (it's not useful for me). As Igor noted, the sockaddr_in is only for IPv4, and type-casting it to anything else (given the size was enough) is bulky with references, so a pointer makes more sense. In my patch, I use sockaddr_in6 internally which should be large enough for most protocols (do we really need more than IPv4 and IPv6 support?). This is done _internally_ so it doesn't require anything from anyone, just regular sockaddr* management which everyone should be comfortable with. If Ross still wants this as a strict IPv4, feel free to change this. Since this new virtual function provides a way for tracking sessions (and thereby gives you the opportunity to store their IP/port in whatever fashion you prefer, if at all used), the previous patch's clientSocket parameter acts as a reference to the accepted session. However, this function is currently only called for the DESCRIBE command. A program using liveMedia can never know/track what commands a client are sending. This is (as far as I can understand) what the original author of this thread was asking for (and what I have been using for a while now). I can't however see the reason for overloading incomingRequestHandler1 since it is doing all the socket reading for you. Therefore, the second part of my patch: To know whatever successful commands have been received by liveMedia, another virtual function is available. This enables an end application to track whatever a client is doing. This does not return Boolean, since it cannot break (deny access to) the liveMedia functionality. The command has already been accepted by the specialClientAccessCheck. Definition: virtual void commandSuccess(int clientSocket, char const* cmd, char const* urlSuffix, const char* fullRequestStr); Obviously, this also uses the clientSocket as a reference to what session/client it refers to. The cmd is the command being sent from the client (OPTIONS, DESCRIBE, TEARDOWN, PLAY, PAUSE, SETUP, etc). The urlSuffix is the server resource being requested (whatever is after the first slash after the ip/domainname). fullRequestStr provides the entire header, which can be especially useful in debugging. Moreover, since the authorization (until now) only occurs on DESCRIBE (authenticationOK is only called from handleCmd_DESCRIBE), clients who ignores this (Amino) can still play streams, since the PLAY command isn't checked for authorization (trust me, I just tried the patch provided in this thread). This is a serious flaw. I have modified the specialClientAccessCheck so that it brings the command as well, and added it to the PLAY, PAUSE and TEARDOWN (add more if you want) functions, so that you can control exactly whatever commands are allowed for whatever resource from whatever client. Comment 1: I would suggest to rename specialClientAccessCheck into something like authorizeResource or authorizeSessionCommand. There is nothing "special" about this function, and Check? All virtual functions which are more than pure notifiers are checks somehow, should they also be called *Check? This is my personal view. Other than that, I have tried to follow Ross' coding style to the extent I could see one. Comment 2: It is very difficult to follow the development of liveMedia and cooperate by sending patches when there is no source code repository to regularly update. Manually diffing the tar.gz tree is cumbersome. I wrote this patch mainly for the first release in this thread, but had to re-diff everything in the new (the source is small, ok, but it's still maybe easier not to send a patch at all, and who gains from that?). I just hope there's not yet another tarball to unpack and diff before I finally send this mail... Cheers, Gustaf -------------- next part -------------- A non-text attachment was scrubbed... Name: authorize.patch Type: text/x-patch Size: 6823 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070424/a0683117/attachment.bin From opera at kth.se Tue Apr 24 04:12:19 2007 From: opera at kth.se (=?ISO-8859-1?Q?Gustaf_R=E4ntil=E4?=) Date: Tue, 24 Apr 2007 13:12:19 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> Message-ID: <462DE613.9070400@kth.se> Ross Finlayson wrote: >> Actually there is problem here with sockaddr_in. It explicitly >> excludes sockaddr_in6. It would better just to use sockaddr to >> simplify IPV6 porting later. >> > > The actual parameter to the call is a "sockaddr_in", so that's what I > used for the formal parameter. > > There are many many places in the code that are IPv4-specific, > unfortunately. (The networking (groupsock) code will need to undergo > a major restructuring before IPv6 could be supported...) > Correction, I typo'ed the definition of the sessionAccept function in the description I wrote, but if you looked at the patch, you'd see the correct one: virtual Boolean sessionAccept(int clientSocket, const struct sockaddr* clientAddr, SOCKLEN_T clientAddrLen); Just to make things clear. Gustaf From vinodjoshi at tataelxsi.co.in Tue Apr 24 04:20:52 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Tue, 24 Apr 2007 16:50:52 +0530 Subject: [Live-devel] Program stream decoder Message-ID: <000001c78662$9f18fb40$022a320a@telxsi.com> Hi all, I am using Live 555 streaming server to stream mpeg2 ts to the st top box. Currently i have the Transport stream decoder with which we are able to stream .ts to set top box. Now we want the implementation for program stream. For this i want to know whether server depacketizes program stream into elementary stream and starts streaming or it transmits as ps packets only. We are trying for the solution that to design parser for program stream and pass the buffers to the TS decoder which i am already having. In what format does the server stream program stream? This may not be right place to post this question. But if anyone gives me the link or information to start the work for receiving PS and depacketizing those. Thanking You. From igor at mir2.org Tue Apr 24 05:01:22 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 24 Apr 2007 14:01:22 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: <462DE53A.7050301@kth.se> References: <4619BA3E.9000704@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> <462DE53A.7050301@kth.se> Message-ID: <7dee4710704240501i11a0dd9fgc0c336f2d1bae45b@mail.gmail.com> On 24/04/07, Gustaf R?ntil? wrote: > Ross Finlayson wrote: > >> Actually there is problem here with sockaddr_in. It explicitly > >> excludes sockaddr_in6. It would better just to use sockaddr to > >> simplify IPV6 porting later. > >> > > > > The actual parameter to the call is a "sockaddr_in", so that's what I > > used for the formal parameter. > > > > There are many many places in the code that are IPv4-specific, > > unfortunately. (The networking (groupsock) code will need to undergo > > a major restructuring before IPv6 could be supported...) In this regard not passing sockaddr_in to specialClientAccessCheck was the right solution as getpeername returns the proper address. Note also that switching from sockaddr_in to sockaddr would also require to pass the address size parameter as otherwise IPv6-compatible code would be clattered with sizeof(sockaddr_ip), sizeof(sockaddr_ipv6). > Definition: > virtual Boolean sessionAccept(int clientSocket, const struct sockaddr* > clientAddr); The same arguments applies, one either passes just clientSocket or include clientAddrLength parameter. > A program using liveMedia can never know/track what commands a > client are sending. The question: is client supposed to call DESCRIBE before calling any other commands within the same TCP session? If so the authentication bug is that the RTSPServer.cpp does not check for that. > Comment 2: > It is very difficult to follow the development of liveMedia and > cooperate by sending patches when there is no source code repository to > regularly update. Manually diffing the tar.gz tree is cumbersome. This is where quilt comes extremely handy, http://savannah.nongnu.org/projects/quilt . It allows to track tar with the same ease as one would use CVS/SVN etc. Regards, Igor From opera at kth.se Tue Apr 24 06:14:11 2007 From: opera at kth.se (=?ISO-8859-1?Q?Gustaf_R=E4ntil=E4?=) Date: Tue, 24 Apr 2007 15:14:11 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: <7dee4710704240501i11a0dd9fgc0c336f2d1bae45b@mail.gmail.com> References: <4619BA3E.9000704@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> <462DE53A.7050301@kth.se> <7dee4710704240501i11a0dd9fgc0c336f2d1bae45b@mail.gmail.com> Message-ID: <462E02A3.4090500@kth.se> Igor Bukanov wrote: > On 24/04/07, Gustaf R?ntil? wrote: > >> Ross Finlayson wrote: >> >>>> Actually there is problem here with sockaddr_in. It explicitly >>>> excludes sockaddr_in6. It would better just to use sockaddr to >>>> simplify IPV6 porting later. >>>> >>>> >>> The actual parameter to the call is a "sockaddr_in", so that's what I >>> used for the formal parameter. >>> >>> There are many many places in the code that are IPv4-specific, >>> unfortunately. (The networking (groupsock) code will need to undergo >>> a major restructuring before IPv6 could be supported...) >>> > > In this regard not passing sockaddr_in to specialClientAccessCheck was > the right solution as getpeername returns the proper address. Note > also that switching from sockaddr_in to sockaddr would also require to > pass the address size parameter as otherwise IPv6-compatible code > would be clattered with sizeof(sockaddr_ip), sizeof(sockaddr_ipv6). > You obviosly didn't read the patch (and/or the second mail where I clarified my typo). And not giving the sockaddr_in requires a new virtual function in your implementation, if you want programs to know when a client has disconnected, or how were you going to fix that? My patch handles this in the same function (and most people probably care for the sockaddr most and the file descriptor the least if at all). >> Definition: >> virtual Boolean sessionAccept(int clientSocket, const struct sockaddr* >> clientAddr); >> > > The same arguments applies, one either passes just clientSocket or > include clientAddrLength parameter. > Again, read my mail. I use clientSocket for 2 things. 1: To _identify_ the session in subsequent calls with the other virtual functions (and the same, for disconnecting). You can't just take it away because you give the address as any sockaddr_xx. 2: It is useful for socket-level manipulations (setsockopt). And the address length parameter _is_ there (and always was in the patch, again I'm sorry for the typo in my description). >> A program using liveMedia can never know/track what commands a >> client are sending. >> > > The question: is client supposed to call DESCRIBE before calling any > other commands within the same TCP session? If so the authentication > bug is that the RTSPServer.cpp does not check for that. > What? I just wrote, that it's not enough to trust that clients won't send PLAY after an "unauthorized" DESCRIBE. That's why I fixed it in the patch also. And obviously some clients _don't_ give a wuzz about DESCRIBE at all, so putting any trust in that is nuts. In my patch, the authorization function (with my session callback, or with the current user/pass class) is called from the other (critical) command functions. >> Comment 2: >> It is very difficult to follow the development of liveMedia and >> cooperate by sending patches when there is no source code repository to >> regularly update. Manually diffing the tar.gz tree is cumbersome. >> > > This is where quilt comes extremely handy, > http://savannah.nongnu.org/projects/quilt . It allows to track tar > with the same ease as one would use CVS/SVN etc. > > I will look into that, thanks for the hint! Gustaf From igor at mir2.org Tue Apr 24 07:34:44 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 24 Apr 2007 16:34:44 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: <462E02A3.4090500@kth.se> References: <4619BA3E.9000704@crystalballinc.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> <462DE53A.7050301@kth.se> <7dee4710704240501i11a0dd9fgc0c336f2d1bae45b@mail.gmail.com> <462E02A3.4090500@kth.se> Message-ID: <7dee4710704240734s55019879h515a9d406dd38ece@mail.gmail.com> On 24/04/07, Gustaf R?ntil? wrote: > Igor Bukanov wrote: > > The question: is client supposed to call DESCRIBE before calling any > > other commands within the same TCP session? If so the authentication > > bug is that the RTSPServer.cpp does not check for that. > > > What? I just wrote, that it's not enough to trust that clients won't > send PLAY after an "unauthorized" DESCRIBE. That's why I fixed it in the > patch also. And obviously some clients _don't_ give a wuzz about > DESCRIBE at all, so putting any trust in that is nuts. In my patch, the > authorization function (with my session callback, or with the current > user/pass class) is called from the other (critical) command functions. Right, one really needs to check for allowed ip address before starting a session as your patch is doing. The only problem with the patch is that incomingConnectionHandler1 needs to close the clientSocket when sessionAccept fails. Regards, Igor > >> Comment 2: > >> It is very difficult to follow the development of liveMedia and > >> cooperate by sending patches when there is no source code repository to > >> regularly update. Manually diffing the tar.gz tree is cumbersome. > >> > > > > This is where quilt comes extremely handy, > > http://savannah.nongnu.org/projects/quilt . It allows to track tar > > with the same ease as one would use CVS/SVN etc. > > > > > I will look into that, thanks for the hint! > > Gustaf > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From finlayson at live555.com Tue Apr 24 07:58:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2007 07:58:41 -0700 Subject: [Live-devel] RTSP server extending In-Reply-To: <462DE53A.7050301@kth.se> References: <4619BA3E.9000704@crystalballinc.com> <461A62E5.8040900@crystalballinc.com> <461B9639.7050907@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> <462DE53A.7050301@kth.se> Message-ID: I don't have time to read through all this, but - for now at least - I'm not going to be making any more changes to the signature of (or call to) the "specialClientAccessCheck()" virtual function. As far as I can tell, this function is sufficient to implement any non-standard access checking, based on the identity of the client, and/or the URL that it's trying to access. (The standard, password-based "Digest authentication" mechanism is more flexible anyway.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Apr 24 08:07:54 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2007 08:07:54 -0700 Subject: [Live-devel] Program stream decoder In-Reply-To: <000001c78662$9f18fb40$022a320a@telxsi.com> References: <000001c78662$9f18fb40$022a320a@telxsi.com> Message-ID: > I am using Live 555 streaming server to stream mpeg2 ts to the st top >box. > Currently i have the Transport stream decoder with which we are able to >stream .ts to set top box. > Now we want the implementation for program stream. > For this i want to know whether server depacketizes program stream into >elementary stream and starts streaming or it transmits as ps packets only. MPEG Program Streams are streamed as separate audio and video RTP streams, because that's the standard way such data is streamed. If you instead want to stream the data as a single, compbined audio+video stream, then you would need to convert your Program Stream data to Transport Streams first (e.g., using code simiilar to that which we use in our "testMPEG1or2ProgramToTransportStream" demo application). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From igor at mir2.org Tue Apr 24 08:10:53 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 24 Apr 2007 17:10:53 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: <7dee4710704240734s55019879h515a9d406dd38ece@mail.gmail.com> References: <4619BA3E.9000704@crystalballinc.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> <462DE53A.7050301@kth.se> <7dee4710704240501i11a0dd9fgc0c336f2d1bae45b@mail.gmail.com> <462E02A3.4090500@kth.se> <7dee4710704240734s55019879h515a9d406dd38ece@mail.gmail.com> Message-ID: <7dee4710704240810j7c8776a3s8df8147b169aa10b@mail.gmail.com> After looking into RTSPServer.cpp code and my current implementation of the server I think the right solution would be to allow for RTSPServer subclass to supply a subclass of RTSPClientSession through a virtual method like createNewClientSession(clientSocket, address, addressLength) Then RTSPClientSession.incomingRequestHandler1 should be modified to to call a new virtial RTSPClientSession method like dispatchCommand that should perform command dispatch based on name and url parameters. In this way a subclass of RTSPServer can check in createNewClientSession for client access restrictions and in a subclass of RTSPClientSession can perform before-after dispatch actions from a custom dispatchCommand implementation. Regards, Igor From opera at kth.se Tue Apr 24 08:23:38 2007 From: opera at kth.se (=?ISO-8859-1?Q?Gustaf_R=E4ntil=E4?=) Date: Tue, 24 Apr 2007 17:23:38 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: <7dee4710704240734s55019879h515a9d406dd38ece@mail.gmail.com> References: <4619BA3E.9000704@crystalballinc.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> <462DE53A.7050301@kth.se> <7dee4710704240501i11a0dd9fgc0c336f2d1bae45b@mail.gmail.com> <462E02A3.4090500@kth.se> <7dee4710704240734s55019879h515a9d406dd38ece@mail.gmail.com> Message-ID: <462E20FA.8050907@kth.se> Igor Bukanov wrote: > On 24/04/07, Gustaf R?ntil? wrote: > >> Igor Bukanov wrote: >> >>> The question: is client supposed to call DESCRIBE before calling any >>> other commands within the same TCP session? If so the authentication >>> bug is that the RTSPServer.cpp does not check for that. >>> >>> >> What? I just wrote, that it's not enough to trust that clients won't >> send PLAY after an "unauthorized" DESCRIBE. That's why I fixed it in the >> patch also. And obviously some clients _don't_ give a wuzz about >> DESCRIBE at all, so putting any trust in that is nuts. In my patch, the >> authorization function (with my session callback, or with the current >> user/pass class) is called from the other (critical) command functions. >> > > Right, one really needs to check for allowed ip address before > starting a session as your patch is doing. The only problem with the > patch is that incomingConnectionHandler1 needs to close the > clientSocket when sessionAccept fails. > > Regards, Igor > Correct. I used to have function pointers as callbacks, so my patch was rewritten (into virtual functions) and this got lost. A close() is needed as you say. I'm sorry for this. But Ross is satisfied with your solution, even though you can't track connections, what they're doing, when they're disconnecting, or disallowing a client to "PLAY" (which at least I consider pretty serious), and controlling authorization for individual resources and commands. I have what I need, and I shared it here. Hopefully more people than me and Vlad will find it useful. Cheers, Gustaf From igor at mir2.org Tue Apr 24 08:25:17 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 24 Apr 2007 17:25:17 +0200 Subject: [Live-devel] RTSP server extending In-Reply-To: References: <4619BA3E.9000704@crystalballinc.com> <7dee4710704200403p428799f8l62c23df224e4de69@mail.gmail.com> <462C833F.3020302@kth.se> <7dee4710704240141p5e906307yb3fbec5fe6220719@mail.gmail.com> <7dee4710704240202j389855a5y3267f9f3a519d845@mail.gmail.com> <462DE53A.7050301@kth.se> Message-ID: <7dee4710704240825k21286796jcb772a9106570dc6@mail.gmail.com> On 24/04/07, Ross Finlayson wrote: > (The standard, password-based "Digest authentication" mechanism is > more flexible anyway.) The reason I need to check for url-client IP is to allow integration with a web server. When the web server shows a user a page with RTSP video objects, a user is already authenticated and a cookie is used to maintain the HTTP session. Thus the idea is to embed the coockie into rtsp urls. Then to authorize the user the video server would simply pass the client ip address and the coockie together with video name to the web server asking for a confirmation if this client has permissions to access a particular video. Digest authentication is useless for this, one really needs specialClientAccessCheck. Regards, Igor From xcsmith at rockwellcollins.com Tue Apr 24 09:44:16 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Tue, 24 Apr 2007 11:44:16 -0500 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss Message-ID: I am willing to work with anyone who wants to help in order to solve our problem (...) I do not imply that the source of the problem is software, however, from our observations it's hard to conclude that the WAN is to blame (although it's the first impression). I am trying to make the server to send packets which would go through the WAN without problems. Please be assured - we have enough bandwidth to send the data. And also - reducing max packet size DID have some impact on the lost packets vs received packets ratio, not perfect, but it DID improve the sittuation to some degree. Re: Maybe this is a newbie idea, but did you check the TTL? I thought the default set by the LIVE should be pretty low. I'm no network buff, but my understanding is that if TTL is too low, "repeaters" down the line will drop the packet after a few hops. How are you checking which packets have gone missing in Ethereal? Are you seeing gaps in the RTP sequence numbers of arriving packets? You can also use ethereal to look at the RTCP RR (receiver report) your client (VLC) is sending, in which it will report packet loss. What happens if you request the stream via UDP? Does the stream get worse or stay about the same? Ross should please correct me here, but does TCP offer that much benefit over UDP for real-time video playback? If a packet arrives too late, it won't be useful except when doing a recording. Also, your email says you are using ATM (Asynchronous Transfer Mode?). I check this on wikipedia, and notice that the data must be divided into very small cells for delivery. It seems like ATM is a protocol for time-sensitive data, like VoIP. RTP also is designed to meet special timing needs of the data. Could there be a problem combining these two time-sensitive protocols? "If a circuit is exceeding its traffic contract, the network can either drop the cells or mark the Cell Loss Priority (CLP) bit (to identify a cell as discardable further down the line)." The RTP delivery can be somewhat bursty, so maybe you need to check your ATM contract and make sure you have the correct one (VBR maybe?) one? Well, I hope there are some ideas here anyway. I'd be interested in hearing what you find out, I also have some packet loss in my system, but I think it's resource or OS related for me. Xochitl From silencertr at gmail.com Tue Apr 24 09:56:58 2007 From: silencertr at gmail.com (Cihat Goktug Gurler) Date: Tue, 24 Apr 2007 19:56:58 +0300 Subject: [Live-devel] Timing Issue on Processing of a Received Packet Message-ID: Hi, I'm now working on a multiview H264 server and client pair. The idea is to receive different views of an object and than merge those images in a way that it will result in 3D view of the object with special displays such as lenticular sheet. I'm not very familiar with the thread structure of VLC, therefore I had the following question in mind. Shortly what happens if the thread that receives the NALU is also used to process the image. Would the delay cause packet loss? The details is as follows; We have a class named as 'H264PlayerSink' which inherits 'MediaSink' class. The number of instances from that class equals to the number of streams we have, which is also equal to the number of views. In order to generate correctly merged images we have to process the frames that belong to same time instance. For this reason we have a buffing mechanism to deal with delayed packets. This buffer passes the NALU information from all views only if all of them arrived. It seems that producing the *merged frame and putting it into FrameBuffer takes around 30ms. Finally the question. If this is done with the same thread that is running on afterGettingFrame method of H264Playersink would that cause packet loss? Since packets arrive with a faster rate. I read that VLC is not multi-threaded.So I thought that if a time consuming (around 30ms) duty is assigned at afterGettingFrame method it may cause a problem. What is your oppinion about that situation? Should I create a new thread (pThread with mutexs) to deal with the merging issue? If I do that afterGettingFrame will only take around 5 ms. I hope the question does not need any clarification. Best wishes Goktug Gurler Koc University / Turkey PS: We are working on a PC with Intel Core2Duo 2600Mhz and OS is WinXP. -- Cihat G?ktu? G?rler ENG. 123 | phone 2653 Electric & Electronic Engineer, Koc University, Turkey. Email: cgurler at ku.edu.tr silencer at nebula.gen.tr silencertr at gmail.com From finlayson at live555.com Tue Apr 24 12:56:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2007 12:56:11 -0700 Subject: [Live-devel] Timing Issue on Processing of a Received Packet In-Reply-To: References: Message-ID: I don't really understand your question, but it seems likely that you haven't read the FAQ - especially the entry about thread safety. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Tue Apr 24 13:04:03 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Tue, 24 Apr 2007 15:04:03 -0500 Subject: [Live-devel] RTSP Server 400 response terminates server-side connection Message-ID: Ross, I am troubleshooting my openRTSP-based application using mediaServer. My client terminates with the error "Broken Pipe." I have traced this back to happening in RTSPClient::sendRequest() at the line where send () is called. I hope you could read through my description of the problem and tell me if you think my analysis is correct: My RTSP client is inherited from RTSPClient class, and it's main difference is to operate in connectionless mode when needed. So after each RTSP message it calls RTSPClient::resetTCPSockets(). But I need to allow the user the option to work in connection-oriented mode. So, I created a function "Boolean setConnectionOrientedMode(Boolean stayConnected)." Now, when I use my client, first I do DESCRIBE & SETUP, then I call the setConnectionOrientedMode(True) so that the client will not disconnect anymore. (I know that the mediaServer will not allow me to disconnect after SETUP, but keep reading.) The next message I sent was a test message, to show that the LIVE555 server will respond to anything ending in . (To demonstrate mediaServer meets requirements.) So I send the message "GARBAGE\r\n\r\n". mediaServer replies with 400 Bad Request. Perfect. Now, the NEXT time I send a message, no matter what RTSP message it is, my client does not send the message (verified in ethereal) and terminates with "Broken Pipe." I looked through the RTSPServer::RTSPClientSession class, and I see that when a 400-type error code is generated, RTSPServer::RTSPClientSession sets fSessionIsActive = false. So, what I think happens is that the RTSPClientSession created to handle the incoming "GARBAGE message" errors & cleans up the connection. Then, my RTSPClient doesn't take into account that the server closed the connection. The next time I send an RTSP message, the server-side disconnect causes my client to choke and die with error "Broken Pipe". (openRTSP terminates when there is an RTSP problem, so this type of thing doesn't happen to openRTSP.) Does this sound on the money? Thanks very much for your input! Xochitl From silencertr at gmail.com Tue Apr 24 15:50:05 2007 From: silencertr at gmail.com (Cihat Goktug Gurler) Date: Wed, 25 Apr 2007 01:50:05 +0300 Subject: [Live-devel] Timing Issue on Processing of a Received Packet In-Reply-To: References: Message-ID: Hi, May be I should simplify the question. The issue is the following. We have a new MediaSink and there is a image processing duty when AfterGettingFrame method is invoked. My question is, if that duty takes around 40ms, would that cause a packet loss? I'm suspicious about this issue because the packets arrive with a faster rate. If there is only a single thread it will be too busy with image processing and it will not be able to read from network interface as frequently as it should. Would that cause packet loss? Should I implement a thread to deal with the image processing? Best wishes, Goktug Gurler On 4/24/07, Ross Finlayson wrote: > I don't really understand your question, but it seems likely that you > haven't read the FAQ - especially the entry about thread safety. > -- > > 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 > -- Cihat G?ktu? G?rler ENG. 123 | phone 2653 Electric & Electronic Engineer, Koc University, Turkey. Email: cgurler at ku.edu.tr silencer at nebula.gen.tr silencertr at gmail.com From finlayson at live555.com Tue Apr 24 17:43:59 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2007 17:43:59 -0700 Subject: [Live-devel] Timing Issue on Processing of a Received Packet In-Reply-To: References: Message-ID: >May be I should simplify the question. The issue is the following. > >We have a new MediaSink and there is a image processing duty when >AfterGettingFrame method is invoked. My question is, if that duty >takes around 40ms, would that cause a packet loss? No, because incoming packets will be buffered by the operating system before they get read. By default, the code ensures that the operating system buffer (for each socket) is at least 50 kBytes in size. If you wish, you can increase that buffer size even larger, by calling "increaseReceiveBufferTo()". > I'm suspicious >about this issue because the packets arrive with a faster rate. If >there is only a single thread it will be too busy with image >processing and it will not be able to read from network interface as >frequently as it should. Would that cause packet loss? No, provided that the (single) thread has enough CPU power to do both the "image processing" and the receiving/handling of network packets. I.e., if *every* packet takes 40 ms to process, and packets arrive less than 40 ms apart *on average*, then you're in trouble (and multiple threads will not be able to help you). However, if packets arrive more than 40 ms apart *on average*, then you should be OK. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From davidlo.net at msa.hinet.net Tue Apr 24 18:34:19 2007 From: davidlo.net at msa.hinet.net (David Lo) Date: Wed, 25 Apr 2007 09:34:19 +0800 Subject: [Live-devel] implement a socket to listen for incomming packets in liveMedia Message-ID: <200704250134.JAA13167@msr53.hinet.net> Hi all, I'm new to using the live555 library, still a little confused on how to use it I'm trying to feed live stream mpeg4 video into liveMedia server, however, I'm Unable to send it using a pipeline under linux pipe. So, I'm thinking to Use socket instead. My encoder will send data to localhost using a socket. And I want to modify the LiveMedia Server to read from this socket and provide it to a media sink. Could anyone give me some pointers on how to do this? Thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070424/970e03d1/attachment.html From ken.hilliard at gmail.com Tue Apr 24 20:46:04 2007 From: ken.hilliard at gmail.com (Ken Hilliard) Date: Wed, 25 Apr 2007 10:46:04 +0700 Subject: [Live-devel] Amino STB Compatibility Message-ID: <4b531160704242046k4b0f0477hf9963c359e7252eb@mail.gmail.com> I would like to use the Live555 Media server with Amino set-top boxes to build a VOD. Does anyone out there have any experience in this area? I'm only looking at implementing "play" and (possibly) "pause" features. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070424/d9724ad7/attachment.html From davidlo.net at msa.hinet.net Tue Apr 24 21:10:35 2007 From: davidlo.net at msa.hinet.net (David Lo) Date: Wed, 25 Apr 2007 12:10:35 +0800 Subject: [Live-devel] implement a socket to listen for incomming packets inliveMedia In-Reply-To: <200704250134.JAA13167@msr53.hinet.net> Message-ID: <200704250410.MAA12762@msr11.hinet.net> Sorry, let me elaborate a little more. I'm trying to feed a live stream mpeg4 data to mediaServer instead of using a file. I've also created a new class MPEG4VideoFileServerMediaSubssionRoute which is based on MPEG4VideoFileServerMediaSubssionRoute except, it's taking the input from a BasicUDPSource instead of a ByteStreamFileSource. It all compiles out okay, and it could run as well, But when I try to connect to the server with a player. Then, the server give out a "Segmentation fault" message. I believe that MPEG4VideoStreamFramer take in FramedSource. Which both BasicUDPSource and ByteStreamFileSource represents. Did I do something wrong? I've provided a snippet on the implementations. FramedSource* MPEG4VideoFileServerMediaSubsessionRoute ::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 500; // kbps, estimate char* inputAddressStr = "239.255.42.42"; struct in_addr inputAddress; inputAddress.s_addr = our_inet_addr(inputAddressStr); Port const inputPort(fportNum); unsigned char const inputTTL = 0; // we're only reading from this mcast group Groupsock inputGroupsock(envir(), inputAddress, inputPort, inputTTL); FramedSource* source = BasicUDPSource::createNew(envir(), &inputGroupsock); return MPEG4VideoStreamFramer::createNew(envir(), source); } Can someone help me?? Thanks in advance David _____ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of David Lo Sent: Wednesday, April 25, 2007 9:34 AM To: live-devel at ns.live555.com Subject: [Live-devel] implement a socket to listen for incomming packets inliveMedia Hi all, I'm new to using the live555 library, still a little confused on how to use it I'm trying to feed live stream mpeg4 video into liveMedia server, however, I'm Unable to send it using a pipeline under linux pipe. So, I'm thinking to Use socket instead. My encoder will send data to localhost using a socket. And I want to modify the LiveMedia Server to read from this socket and provide it to a media sink. Could anyone give me some pointers on how to do this? Thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070424/a3a2458f/attachment-0001.html From finlayson at live555.com Tue Apr 24 18:49:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2007 18:49:43 -0700 Subject: [Live-devel] implement a socket to listen for incomming packets in liveMedia In-Reply-To: <200704250134.JAA13167@msr53.hinet.net> References: <200704250134.JAA13167@msr53.hinet.net> Message-ID: > I'm new to using the live555 library, still a little confused on >how to use it >I'm trying to feed live stream mpeg4 video into liveMedia server The "live555MediaServer" product does not (yet) support live input streams. However, you can use our source code to build your own RTSP server that streams from a live input source. If your input source is MPEG-4 video, you can use - as a starting point - our "testMPEG4VideoStreamer" demo application (for multicast streaming), or "testOnDemandRTSPServer" (for unicast streaming). 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070424/ab8095d8/attachment.html From finlayson at live555.com Tue Apr 24 22:57:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Apr 2007 22:57:11 -0700 Subject: [Live-devel] Amino STB Compatibility In-Reply-To: <4b531160704242046k4b0f0477hf9963c359e7252eb@mail.gmail.com> References: <4b531160704242046k4b0f0477hf9963c359e7252eb@mail.gmail.com> Message-ID: >I would like to use the Live555 Media server with Amino set-top >boxes to build a VOD. You can do this already - streaming MPEG Transport Stream files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vinodjoshi at tataelxsi.co.in Wed Apr 25 00:33:50 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Wed, 25 Apr 2007 13:03:50 +0530 Subject: [Live-devel] Program stream decoder In-Reply-To: Message-ID: <006001c7870c$12520170$022a320a@telxsi.com> Thank you for your reply. I want to know that whether MPEG2 PS is streamed as PES or ES. If Elementary Stream then, whether audio and video streams are differentiated by means of RTP header? -----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, April 24, 2007 8:38 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Program stream decoder > I am using Live 555 streaming server to stream mpeg2 ts to the st top >box. > Currently i have the Transport stream decoder with which we are able to >stream .ts to set top box. > Now we want the implementation for program stream. > For this i want to know whether server depacketizes program stream into >elementary stream and starts streaming or it transmits as ps packets only. MPEG Program Streams are streamed as separate audio and video RTP streams, because that's the standard way such data is streamed. If you instead want to stream the data as a single, compbined audio+video stream, then you would need to convert your Program Stream data to Transport Streams first (e.g., using code simiilar to that which we use in our "testMPEG1or2ProgramToTransportStream" demo application). -- 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 billycheng at seed.net.tw Wed Apr 25 02:36:51 2007 From: billycheng at seed.net.tw (Fu-Yuan Cheng) Date: Wed, 25 Apr 2007 17:36:51 +0800 (CST) Subject: [Live-devel] About -i option and output as AVI format with DivX 4 Message-ID: <7721343.12951177493811206.JavaMail.root@wm11.seed.net.tw> Hello, I connect a IP-CAM and use openRTSP to grab it's MPEG4 frame via RTSP. I use such command: ./openRTSP -i -w 640 -h 480 -f 15 -e 30 rtsp://192.168.1.166/mpeg4 > skinner.avi Below is running result: Opened URL "rtsp://192.168.1.166/mpeg4" Created receiver for "video/MP4V-ES" subsession (client ports 32780-32781) Created receiver for "audio/PCMU" subsession (client ports 32782-32783) Setup "video/MP4V-ES" subsession (client ports 32780-32781) Setup "audio/PCMU" subsession (client ports 32782-32783) Started playing session Receiving streamed data (for up to 30.000000 seconds)... I check the format of this skinner.avi file by using "file skinner.avi" and the result is below: skinner.avi: RIFF (little-endian) data, AVI, 640 x 480, ~15 fps, video: DivX 4, audio: (mono, 8000 Hz) By the way, when I put this skinner.avi on M$ and use WMP with DivX codec, WMP can't play it and told that not support this kind of file or codec. I use AVIcodec to check this skinner.avi and it shows: video: DIVX = openDivx v4, supported audio: CCITT u-Law, VBR, supported Well, does anyone tell me why or what's the problem? Thanks very very much~ with regards, skinner From billycheng at seed.net.tw Wed Apr 25 02:36:51 2007 From: billycheng at seed.net.tw (Fu-Yuan Cheng) Date: Wed, 25 Apr 2007 17:36:51 +0800 (CST) Subject: [Live-devel] About -i option and output as AVI format with DivX 4 Message-ID: <8885695.12961177493811650.JavaMail.root@wm11.seed.net.tw> Hello, I connect a IP-CAM and use openRTSP to grab it's MPEG4 frame via RTSP. I use such command: ./openRTSP -i -w 640 -h 480 -f 15 -e 30 rtsp://192.168.1.166/mpeg4 > skinner.avi Below is running result: Opened URL "rtsp://192.168.1.166/mpeg4" Created receiver for "video/MP4V-ES" subsession (client ports 32780-32781) Created receiver for "audio/PCMU" subsession (client ports 32782-32783) Setup "video/MP4V-ES" subsession (client ports 32780-32781) Setup "audio/PCMU" subsession (client ports 32782-32783) Started playing session Receiving streamed data (for up to 30.000000 seconds)... I check the format of this skinner.avi file by using "file skinner.avi" and the result is below: skinner.avi: RIFF (little-endian) data, AVI, 640 x 480, ~15 fps, video: DivX 4, audio: (mono, 8000 Hz) By the way, when I put this skinner.avi on M$ and use WMP with DivX codec, WMP can't play it and told that not support this kind of file or codec. I use AVIcodec to check this skinner.avi and it shows: video: DIVX = openDivx v4, supported audio: CCITT u-Law, VBR, supported Well, does anyone tell me why or what's the problem? Thanks very very much~ with regards, skinner From billycheng at seed.net.tw Wed Apr 25 02:58:48 2007 From: billycheng at seed.net.tw (Fu-Yuan Cheng) Date: Wed, 25 Apr 2007 17:58:48 +0800 (CST) Subject: [Live-devel] Another question about audio PCMU Message-ID: <26940881.13571177495128730.JavaMail.root@wm11.seed.net.tw> Hello again, I try to use openRTSP to grab MPEG4 frame from a IP-CAM and output as QuickTime MP4 format. I use such command: ./openRTSP -4 -w 640 -h 480 -f 15 -e 30 rtsp://192.168.1.166/mpeg4 > skinner.mp4 And the messages after running is below: Opened URL "rtsp://192.168.1.166/mpeg4" Created receiver for "video/MP4V-ES" subsession (client ports 32782-32783) Created receiver for "audio/PCMU" subsession (client ports 32784-32785) Setup "video/MP4V-ES" subsession (client ports 32782-32783) Setup "audio/PCMU" subsession (client ports 32784-32785) width = 640, height = 480, fps = 15 width = 640, height = 480, fps = 15 Started playing session Receiving streamed data (for up to 30.000000 seconds)... I can use WMP on M$ to play this skinner.mp4 with 3ivx codec. However, it just show video but no audio. Yes, it has video show but soundless. I am sure that openRTSP really recognize this audio format and grab it. But why it is soundless if I play this mp4 file? By the way, if I use realplayer or QuickTime on M$ and connect the rtsp stream from IP-CAM, it really show both video and audio. So, what is the problem? Maybe anyone could give me some hints or other? Thanks very much and big thank. best regards, skinner From finlayson at live555.com Wed Apr 25 02:44:48 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Apr 2007 02:44:48 -0700 Subject: [Live-devel] Program stream decoder In-Reply-To: <006001c7870c$12520170$022a320a@telxsi.com> References: <006001c7870c$12520170$022a320a@telxsi.com> Message-ID: >Thank you for your reply. > I want to know that whether MPEG2 PS is streamed as PES or ES. Separate Elementary streams - for audio and video. (Didn't I already answer this?) > If Elementary Stream then, whether audio and video streams are >differentiated by means of RTP header? The audio and video streams have different RTP payload type codes, and are also sent to different ports. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ken.hilliard at gmail.com Wed Apr 25 03:46:21 2007 From: ken.hilliard at gmail.com (Ken Hilliard) Date: Wed, 25 Apr 2007 17:46:21 +0700 Subject: [Live-devel] Amino STB Compatibility In-Reply-To: References: <4b531160704242046k4b0f0477hf9963c359e7252eb@mail.gmail.com> Message-ID: <4b531160704250346t29e71b61o94c7ea395d985c7f@mail.gmail.com> Thanks Ross. I was also interested in knowing if the current version would be stable enough in a production environment, 24x7 operation. It software looks ideal but I didn't know how long the support for amino's rtsp style has been included. BTW: Do you know of any software that can remux h.264 into mpegts? Everything open source I've tried (mencoder, avidemux, vlc, etc.) is very buggy as far as support for h.264 content goes. I've given up and going to by Elecard's XMuxer Lite. Unfortunately it only works under Windows. Urggh! On 4/25/07, Ross Finlayson wrote: > > >I would like to use the Live555 Media server with Amino set-top > >boxes to build a VOD. > > You can do this already - streaming MPEG Transport Stream files. > -- > > 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: http://lists.live555.com/pipermail/live-devel/attachments/20070425/fa6929d0/attachment.html From naoufel.xx.fitouhi at ericsson.com Wed Apr 25 08:18:49 2007 From: naoufel.xx.fitouhi at ericsson.com (NAOUFEL FITOUHI XX (TN/BTN)) Date: Wed, 25 Apr 2007 17:18:49 +0200 Subject: [Live-devel] 3gp supproting VOD Message-ID: <535FDABD0CD49A458B27FC9D6175CDBCAFF0EE@esealmw115.eemea.ericsson.se> Hi every body I m working on live555 VOD but I can't find 3gp file format can anybody tell me how to use this format ? Cest Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070425/10ffbd7c/attachment.html From shaswata at alumnux.com Wed Apr 25 08:27:57 2007 From: shaswata at alumnux.com (Shaswata Jash) Date: Wed, 25 Apr 2007 20:57:57 +0530 Subject: [Live-devel] 3gp supporting VOD In-Reply-To: <535FDABD0CD49A458B27FC9D6175CDBCAFF0EE@esealmw115.eemea.ericsson.se> References: <535FDABD0CD49A458B27FC9D6175CDBCAFF0EE@esealmw115.eemea.ericsson.se> Message-ID: <001e01c7874e$5fad9a00$2e0aa8c0@alumnusshas> Live yet does not support ISO Base media conforming media files - even the hinted ones. With regards, Shaswata _____ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of NAOUFEL FITOUHI XX (TN/BTN) Sent: Wednesday, April 25, 2007 8:49 PM To: live-devel at ns.live555.com Subject: [Live-devel] 3gp supproting VOD Hi every body I m working on live555 VOD but I can't find 3gp file format can anybody tell me how to use this format ? Cest Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070425/e8ac65bf/attachment-0001.html From morgan.torvolt at gmail.com Wed Apr 25 14:43:38 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 26 Apr 2007 01:43:38 +0400 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: References: Message-ID: <3cc3561f0704251443r778e1b0en9cf2ef7a9038ef37@mail.gmail.com> > Also, your email says you are using ATM (Asynchronous Transfer Mode?). I > check this on wikipedia, and notice that the data must be divided into very > small cells for delivery. It seems like ATM is a protocol for > time-sensitive data, like VoIP. RTP also is designed to meet special > timing needs of the data. Could there be a problem combining these two > time-sensitive protocols? "If a circuit is exceeding its traffic contract, > the network can either drop the cells or mark the Cell Loss Priority (CLP) > bit (to identify a cell as discardable further down the line)." The RTP > delivery can be somewhat bursty, so maybe you need to check your ATM > contract and make sure you have the correct one (VBR maybe?) one? ATM is just a transport layer, as Ethernet, SDH and others. ATM is usually used in for example ADSL connections. That the packet size is 155 (or something like that) is not obvious, or even visible, to the end hardware. It sees only an ordinary Ethernet link. ATM is not very suited to do anything really. It is like a duck, it can swim, fly and make sound, but does neither extremely well. For extremely time sensitive data one uses SDH, which even keeps the original input clock through the links. For time insensitive data one uses Ethernet. ATM is very good at prioritizing traffic though, and it could sound like the Ethernet packets are given a low priority, possibly due to the fact that it is UDP. I have experienced this before, and the configuration of a Ethernet card in one of the nodes was to blame. It did not keep it's config due to hardware failure. In your case this should be configurable in the ATM nodes, or management software. As a "most likely" option, I would have to opt for bandwidth problem. I have spent too many hours saying that it is not so on ATM networks before. Check that your VCs and VPs are set up correctly, and try transmitting TCP and UDP data from other sources than live. VLC stream output would be a good place to start I believe. I agree with Ross here. You say it works well without the ATM, but not with it. The reason for the problems is then too obvious. As there are literally thousands of users of this software, I do believe that the way it handles the Ethernet part works according to standard (unless your OS or some configurations therein is to blame). One should not make custom fixes to allow for broken hardware or configuration. In this case "your network" seems like a good term, as most of the other networks seems to work just fine. -Morgan- From morgan.torvolt at gmail.com Wed Apr 25 14:54:21 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 26 Apr 2007 01:54:21 +0400 Subject: [Live-devel] Timing Issue on Processing of a Received Packet In-Reply-To: References: Message-ID: <3cc3561f0704251454n16e8469fn950d19dab1c35619@mail.gmail.com> > I.e., if *every* packet takes 40 ms to process, and packets arrive > less than 40 ms apart *on average*, then you're in trouble (and > multiple threads will not be able to help you). However, if packets > arrive more than 40 ms apart *on average*, then you should be OK. If Mr. Gurler has a dual core CPU, threading the thing could improve performance, depending on how much CPU power the packet reception system demands. If it is negligable then threading will probably not give any improvement. Also, if the processing is done in chunks, and this makes the input buffer overflow while processing the image, threading could solve the problem. Then again, increasing the buffer would probably work as well, and give less headache regarding race conditions and such. -Morgan- From victor_l2000 at hotmail.com Wed Apr 25 19:43:28 2007 From: victor_l2000 at hotmail.com (Victor Lee) Date: Wed, 25 Apr 2007 19:43:28 -0700 Subject: [Live-devel] VLC uses Live555, UDP streaming out problem Message-ID: Hi Gurus, I am trying to send a mytest.ts file (Transport Stream) via USP. I am doing this experiment on my desktop, Windows XP. I did the following experiments: Exp1: I used VLC 0.8.6a to read mytest.ts, streaming it out via UDP (unicast, set the ip address as my local computer, and a port #). I created a simple UDP server (see below) to receive the stream and then save it into myfile.ts mytest.ts and myfile.ts are different. VLC plays the original file mytest.ts well. But when using VLC to play myfile.ts, there are blocks in the video. Exp2: use VLc to read mytest.ts, and then streaming out via UDP, at the same time, output it to a file, myfile2.ts. Use another VLC to receive this stream (set the port # to 1234). The video received by the 2nd VLC does not have any problem and myfile2.ts does not have any problem. I am wondering why using my application to receive the UDP stream and save into file has problem (the saved file does not need to be exactly the same as mytest.ts, as long as it plays well with VLC), but using VLC to save the file is ok, and using VLC to receive the UDP stream is also fine? When using my simple application to receive the stream, each time i receive a 1316 bytes packet. i can see the settings in the 1st VLC: Stream Output-->UDP as: Caching value(ms) 300 Time-To-Live(TTL) 0 Group packets 1 VLC uses live555, what changes happen in live555 for the process using VLC to stream the file out? Thanks for your help! Victor ------------------------------- #include #include #include #define MAX_MSG 1316 int main() { WSADATA wsaData; WORD wVersionRequested = MAKEWORD( 2, 2 ); WSAStartup(wVersionRequested, &wsaData); int sd, rc, n, cliLen; struct sockaddr_in cliAddr, servAddr; char msg[MAX_MSG]; sd = socket(AF_INET, SOCK_DGRAM, 0); if( sd < 0 ) { exit(1); } servAddr.sin_family = AF_INET; servAddr.sin_addr.s_addr = htonl(INADDR_ANY); servAddr.sin_port = htons(1234); //this is the port VLC used to streaming out mytest.ts with UDP rc = bind (sd, (struct sockaddr *) &servAddr, sizeof(servAddr)); if ( rc < 0 ) { exit(1); } FILE *fp = fopen("myfile.ts", "wb"); cliLen = sizeof(cliAddr); while(1) { memset(msg, 0x0, MAX_MSG); n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) &cliAddr, &cliLen); if(n<0) { exit(-1); } fwrite(msg, n, sizeof(char), fp); } fclose(fp); WSACleanup(); return 0; } _________________________________________________________________ Mortgage rates near historic lows. Refinance $200,000 loan for as low as $771/month* https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f8&disc=y&vers=689&s=4056&p=5117 From finlayson at live555.com Wed Apr 25 21:55:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Apr 2007 21:55:53 -0700 Subject: [Live-devel] VLC uses Live555, UDP streaming out problem In-Reply-To: References: Message-ID: VLC currently uses the "LIVE555 Streaming Media" code only for *receiving* RTSP streams. For transmitting streams, VLC uses separate code. Any questions about transmitting data using VLC should go to a VLC mailing list. However, I suggest that - instead of using VLC - you use the "LIVE555 Media Server" to transmit MPEG Transport Stream files. This server is more standards compliant, more compatible with many set-top boxes, and supports 'trick play' operations. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vinodjoshi at tataelxsi.co.in Wed Apr 25 23:29:52 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Thu, 26 Apr 2007 11:59:52 +0530 Subject: [Live-devel] ES streaming payload differentiation Message-ID: <000801c787cc$4d13f460$022a320a@telxsi.com> Hi, MPEG2 PS is streamed as seperate Audio and Video elementary streams. For receiving both streams on same port we need to differentiate between audio and video. Tthis can be done using RTP header payload type. But for dynamic payload type (from 96-127) any RFC is not specifying how to differentiate audio/video payload or I may not know. So anybody knows how to differentiate A / V payload in case of dynamic payload types? thank you.. From finlayson at live555.com Thu Apr 26 00:18:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Apr 2007 00:18:41 -0700 Subject: [Live-devel] ES streaming payload differentiation In-Reply-To: <000801c787cc$4d13f460$022a320a@telxsi.com> References: <000801c787cc$4d13f460$022a320a@telxsi.com> Message-ID: > MPEG2 PS is streamed as seperate Audio and Video elementary streams. > For receiving both streams on same port we need to differentiate between >audio and video. > Tthis can be done using RTP header payload type. > But for dynamic payload type (from 96-127) any RFC is not specifying how >to differentiate > audio/video payload or I may not know. > So anybody knows how to differentiate A / V payload in case of dynamic >payload types? This mailing list is for the discussion of the "LIVE555 Streaming Media" software. General questions about RTP/RTCP - independent of this software - should instead be sent to some other mailing list. (However, for the answer to your question, read the SDP specification - specifically, the section that describes the "rtpmap" attribtute. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From davidlo.net at msa.hinet.net Thu Apr 26 03:37:25 2007 From: davidlo.net at msa.hinet.net (David Lo) Date: Thu, 26 Apr 2007 18:37:25 +0800 Subject: [Live-devel] implement a socket to listen for incomming packets in liveMedia In-Reply-To: Message-ID: <200704261037.SAA22699@msr31.hinet.net> Hi Ross, After some testing, I was able to stream to testMPEG4VideoStreamer using "stdin" But I couldn't do the same with testOnDemandRTSPServer. After turning on the DEBUG For MPEG4VideoStreamFramer I get a lot of "ignoring non VS header " errors do I need to Implement my own class to take the input from "stdin" and buffer it in the memory then Send it to the Framer? Could you provide some clue? Thanks again. David I'm new to using the live555 library, still a little confused on how to use it I'm trying to feed live stream mpeg4 video into liveMedia server The "live555MediaServer" product does not (yet) support live input streams. However, you can use our source code to build your own RTSP server that streams from a live input source. If your input source is MPEG-4 video, you can use - as a starting point - our "testMPEG4VideoStreamer" demo application (for multicast streaming), or "testOnDemandRTSPServer" (for unicast streaming). 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070426/7b95e295/attachment.html From ilya77 at gmail.com Thu Apr 26 05:33:31 2007 From: ilya77 at gmail.com (ilya77 at gmail.com) Date: Thu, 26 Apr 2007 15:33:31 +0300 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: <3cc3561f0704251443r778e1b0en9cf2ef7a9038ef37@mail.gmail.com> References: <3cc3561f0704251443r778e1b0en9cf2ef7a9038ef37@mail.gmail.com> Message-ID: Hi All, First of all, let me express my gratitude for the elaborate and thoughtful replies from Ross, Xochitl and Morgan, and apologise in advance for the long text below, however - we are quite desparate... We've done some homework in order to answer the questions which have been previously asked, and here are the answers which might hopefully clear things up: We've compared two packet size settings, the default (1448) and a custom (1328 = 188*7 + 12) size. In both cases ethereal showed 43% packet loss (indicated by gaps in RTP sequence numbers). During the test, we have constantly monitored our NAT box, and the bandwidth usage did not exceed 50% of the downstream capacity (and of course the upstream capacity too). We have also examined the RTSP receiver report sent by the VLC player which revealed the following data: a. Packets lost: 6361 b. Fraction lost: 48 / 256 c. Interarrival jitter: 301 I am not an expert enough to understand the interarrival jitter or fraction lost counters, however "packets lost" stand for itself. We've also examined the TTL value of the packets which DID arrive, and it stood on 126 on ALL packets. The RTP stream was sent over TCP, and we will later on try to eliminate the NAT from the equation and try testing with UDP transport. I also think it's a good idea to describe the network topology utilized during the test to make things a bit more clear: Win2003 Server -> 1Gbit switch -> Internet -> ATM -> Checkpoint Safe at Office 500 7.0.33.x -> LAN The internet connection from the checkpoint box is going over PPPoE through the ATM line. The ATM line contract is 4 Mbit downstream and 2 Mbit upstream (we have conducted the test with a transport stream encoded at approximately 2 Mbit/sec.), and the checkpoint box performs traffic shaping effectively limiting the incoming bandwidth at around 3.8 Mbit/sec. >From past experience with multicast (although not 100% relevant in this case since we're using unicast streaming), PPPoE adds some excess overhead to the packets going out of the line, effectively reducing the MTU of the packets which can be sent out of the network, and also causes fragmentation of incoming packets on the IP level (since the incoming MTU is also reduced), and this is the reason we started experimenting with different packet sizes. As you can see, there are quite a few devices and software along the way which could potentially affect the quality of service, yet again, from our extensive experience with Real Media and Windows Media (on the same network infrastructure) those potential infrastructure problems can be (and are) successfully dealt with in commercial software for the sake of the end-user experience. We are trying to do the same with Live555, with no positive results (and no apparent reason for failure) yet. Any help, ideas and thoughts would be kindly appreciated... Many thanks, Ilya On 4/26/07, Morgan T?rvolt wrote: > > > Also, your email says you are using ATM (Asynchronous Transfer > Mode?). I > > check this on wikipedia, and notice that the data must be divided into > very > > small cells for delivery. It seems like ATM is a protocol for > > time-sensitive data, like VoIP. RTP also is designed to meet special > > timing needs of the data. Could there be a problem combining these two > > time-sensitive protocols? "If a circuit is exceeding its traffic > contract, > > the network can either drop the cells or mark the Cell Loss Priority > (CLP) > > bit (to identify a cell as discardable further down the line)." The RTP > > > delivery can be somewhat bursty, so maybe you need to check your ATM > > contract and make sure you have the correct one (VBR maybe?) one? > > ATM is just a transport layer, as Ethernet, SDH and others. ATM is > usually used in for example ADSL connections. That the packet size is > 155 (or something like that) is not obvious, or even visible, to the > end hardware. It sees only an ordinary Ethernet link. > ATM is not very suited to do anything really. It is like a duck, it > can swim, fly and make sound, but does neither extremely well. For > extremely time sensitive data one uses SDH, which even keeps the > original input clock through the links. For time insensitive data one > uses Ethernet. ATM is very good at prioritizing traffic though, and it > could sound like the Ethernet packets are given a low priority, > possibly due to the fact that it is UDP. I have experienced this > before, and the configuration of a Ethernet card in one of the nodes > was to blame. It did not keep it's config due to hardware failure. In > your case this should be configurable in the ATM nodes, or management > software. > > As a "most likely" option, I would have to opt for bandwidth problem. > I have spent too many hours saying that it is not so on ATM networks > before. Check that your VCs and VPs are set up correctly, and try > transmitting TCP and UDP data from other sources than live. VLC stream > output would be a good place to start I believe. > > I agree with Ross here. You say it works well without the ATM, but not > with it. The reason for the problems is then too obvious. As there are > literally thousands of users of this software, I do believe that the > way it handles the Ethernet part works according to standard (unless > your OS or some configurations therein is to blame). One should not > make custom fixes to allow for broken hardware or configuration. In > this case "your network" seems like a good term, as most of the other > networks seems to work just fine. > > -Morgan- > _______________________________________________ > 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: http://lists.live555.com/pipermail/live-devel/attachments/20070426/28529de9/attachment-0001.html From finlayson at live555.com Thu Apr 26 05:54:29 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Apr 2007 05:54:29 -0700 Subject: [Live-devel] implement a socket to listen for incomming packets in liveMedia In-Reply-To: <200704261037.SAA22699@msr31.hinet.net> References: <200704261037.SAA22699@msr31.hinet.net> Message-ID: >After some testing, I was able to stream to testMPEG4VideoStreamer >using "stdin" >But I couldn't do the same with testOnDemandRTSPServer. If you can get "testMPEG4VideoStreamer" to stream from "stdin", then you should also be able to do the same with "testOnDemandRTSPServer". Don't forget to change "reuseFirstSource" to True. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070426/0e483073/attachment.html From sony at mht.bme.hu Fri Apr 27 00:01:22 2007 From: sony at mht.bme.hu (Tran Minh Son) Date: Fri, 27 Apr 2007 09:01:22 +0200 Subject: [Live-devel] AAC streaming Message-ID: <46319FC2.5090509@mht.bme.hu> Dear All, I would like to know how I can use live555 to stream an AAC audio media with RTP/RTCP. I took the example of TestMP3Streamer (turning off the option RTSP) and replace the MP3FileSource , MPEG1or2AudioRTPSink object with MPEG4GenericRTPSource and MPEG4GenericRTPSink object, but it does not work. At the client side, I got the error message that the stream misses the RTP header. I try with the pair ADTSAudioFileSource and MPEG4GenericRTPSink having the same result. I wonder whether I should try with MPEGLAMTAudioSource and MPEGLAMTAudioRTPSink? The latter doesnot have method to accept directly the file name to be streamed. It can be used only as a filter of other source? Thank you in advance for your help Sincerely Son From finlayson at live555.com Fri Apr 27 00:13:58 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2007 00:13:58 -0700 Subject: [Live-devel] AAC streaming In-Reply-To: <46319FC2.5090509@mht.bme.hu> References: <46319FC2.5090509@mht.bme.hu> Message-ID: >Dear All, >I would like to know how I can use live555 to stream an AAC audio media >with RTP/RTCP. Yes. You can use the "LIVE555 Media Server" to stream any AAC (ADTS-format) file whose name ends with ".aac", or you can use "testOnDemandRTSPServer", to stream a file named "test.aac". > I took the example of TestMP3Streamer No, you don't need to do this. We already have applications that can stream AAC audio files. (See above.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sony at mht.bme.hu Fri Apr 27 01:00:19 2007 From: sony at mht.bme.hu (Tran Minh Son) Date: Fri, 27 Apr 2007 10:00:19 +0200 Subject: [Live-devel] AAC streaming In-Reply-To: References: <46319FC2.5090509@mht.bme.hu> Message-ID: <4631AD93.5020602@mht.bme.hu> Dear Ross Finlayson, Thank you for your prompt answer. I know that with Media Server I can stream out the AAC content but in the RTSP manner. Upon the request from client, the media (of type AAC) will be streamed out in the encapsulation of RTP/RTCP. I would like to have something more simpler: the second action only. That is without any control level from RTSP, my server streams out (unicast / multicast) right after starting, does not take into account whether there is any client who wants to receive (send a request). It is the manner of the TestMP3Streamer compiled without option RTSPServer. And I could not migrate it from MP3 to AAC Thank you Son Ross Finlayson a ?crit : >> Dear All, >> I would like to know how I can use live555 to stream an AAC audio media >> with RTP/RTCP. >> > > Yes. You can use the "LIVE555 Media Server" > to stream any AAC (ADTS-format) > file whose name ends with ".aac", or you can use > "testOnDemandRTSPServer", to stream a file named "test.aac". > > >> I took the example of TestMP3Streamer >> > > No, you don't need to do this. We already have applications that can > stream AAC audio files. (See above.) > From finlayson at live555.com Fri Apr 27 01:48:04 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2007 01:48:04 -0700 Subject: [Live-devel] AAC streaming In-Reply-To: <4631AD93.5020602@mht.bme.hu> References: <46319FC2.5090509@mht.bme.hu> <4631AD93.5020602@mht.bme.hu> Message-ID: >I know that with Media Server I can stream out the AAC content but in >the RTSP manner. Upon the request from client, the media (of type AAC) >will be streamed out in the encapsulation of RTP/RTCP. I would like to >have something more simpler: the second action only. That is without any >control level from RTSP No, if you want to stream an AAC audio (ADTS format) file, then you will need to use RTSP, because the stream will have some (file-specific) parameters that can only be communicated in the SDP description (which is delivered to the client using RTSP). If you wish, you can write an application that streams via multicast (rather than unicast), but you will still need to have a built-in RTSP server, and have the clients play the stream using RTSP. In either case, you will be able to play the stream using either VLC or QuickTime Player - using a "rtsp://" URL. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sony at mht.bme.hu Fri Apr 27 02:12:44 2007 From: sony at mht.bme.hu (Tran Minh Son) Date: Fri, 27 Apr 2007 11:12:44 +0200 Subject: [Live-devel] AAC streaming In-Reply-To: References: <46319FC2.5090509@mht.bme.hu> <4631AD93.5020602@mht.bme.hu> Message-ID: <4631BE8C.6090105@mht.bme.hu> Dear Ross Finlayson Thank you very much for your explaination. Up to now I thought that RTSP at most adds the control layer (DESC, SETUP,PLAY,PAUSE..) to the underlying media layer (RTP) to enable the interactivity between server-client, and the RTP stream itself can be treated (decoded) by client without any additional information. Can you explain more in detail what parameters clients need to know in order to decode the RTP stream which contains ADTS audio data. It means that RTP protocol fully supports MP3 but not AAC? I means using single RTP we can stream out for instance MP3, but for AAC we have to couple RTP with some additional protocol like RTSP?. I am terribly sorry if my questions are maybe so naive. This is the first time I have to look deeper inside in the streaming protocol Thank you again for your help and time Best regards Son Ross Finlayson a ?crit : >> I know that with Media Server I can stream out the AAC content but in >> the RTSP manner. Upon the request from client, the media (of type AAC) >> will be streamed out in the encapsulation of RTP/RTCP. I would like to >> have something more simpler: the second action only. That is without any >> control level from RTSP >> > > No, if you want to stream an AAC audio (ADTS format) file, then you > will need to use RTSP, because the stream will have some > (file-specific) parameters that can only be communicated in the SDP > description (which is delivered to the client using RTSP). > > If you wish, you can write an application that streams via multicast > (rather than unicast), but you will still need to have a built-in > RTSP server, and have the clients play the stream using RTSP. > > In either case, you will be able to play the stream using either VLC > or QuickTime Player - using a "rtsp://" URL. > From finlayson at live555.com Fri Apr 27 02:26:27 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2007 02:26:27 -0700 Subject: [Live-devel] AAC streaming In-Reply-To: <4631BE8C.6090105@mht.bme.hu> References: <46319FC2.5090509@mht.bme.hu> <4631AD93.5020602@mht.bme.hu> <4631BE8C.6090105@mht.bme.hu> Message-ID: >Can you explain more in detail what parameters clients need to know in >order to decode the RTP stream which contains ADTS audio data. I don't have time to do this, but if you really care, you can read RFC 3640. However, one important such parameter is sampling frequency. > It means >that RTP protocol fully supports MP3 but not AAC? No, it doesn't mean that at all. All it means is that AAC RTP packets - unlike MP3 RTP packets - are not completely 'self describing'. I.e., a receiver cannot decode the incoming stream just by looking at the contents of the packet. Instead, it will need additional parameters that are included in the SDP description, which clients retrieve using the RTSP protocol. Many other codecs are like this - e.g., PCM audio, MPEG-4 video and H.264 video. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From RQJM87 at motorola.com Fri Apr 27 06:29:18 2007 From: RQJM87 at motorola.com (N Anche Naveen-RQJM87) Date: Fri, 27 Apr 2007 21:29:18 +0800 Subject: [Live-devel] Cannot play an RTSP stream Message-ID: <772484426025194BAC0E4697D0B386D908042B@zmy16exm71.ds.mot.com> Hi, I downloaded live55MediaServer from live555.com and ran it on my linux system. I downloaded live source code and built it according to steps given in http://www.live555.com/liveMedia/#config-unix I downloaded Mplayer and built it. When i try to play an rtsp file, i get an error: Here is the complete log: [root at pclin518 bin]# ./mplayer rtsp://10.232.67.150:8554/dvb_sub.mpeg MPlayer 1.0rc1-4.1.0 (C) 2000-2006 MPlayer Team CPU: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz (Family: 6, Model: 15, Step ping: 6) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 Playing rtsp://10.232.67.150:8554/dvb_sub.mpeg. Resolving 10.232.67.150 for AF_INET6... Couldn't resolve name for AF_INET6: 10.232.67.150 Connecting to server 10.232.67.150[10.232.67.150]: 8554... connect error: Connection refused Resolving 10.232.67.150 for AF_INET6... Couldn't resolve name for AF_INET6: 10.232.67.150 Connecting to server 10.232.67.150[10.232.67.150]: 8554... connect error: Connection refused File not found: '10.232.67.150:8554/dvb_sub.mpeg' Failed to open rtsp://10.232.67.150:8554/dvb_sub.mpeg. Exiting... (End of file) Am I doing something wrong? Thanks, -Naveen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070427/eeb5c872/attachment.html From l1436636 at yahoo.com Fri Apr 27 08:19:51 2007 From: l1436636 at yahoo.com (hong liu) Date: Fri, 27 Apr 2007 08:19:51 -0700 (PDT) Subject: [Live-devel] About the openRTSP source code Message-ID: <433437.41425.qm@web51104.mail.re2.yahoo.com> I start looking at the source code of openRTSP, and try to modify the code to add SPS an PPS NAL units of H264 into saved file. I am a little lost in it. Could you give me a clue of which functions I need to have a look at? By the way, what is the difference in use between H264VideoRTPSource and H264VideoRTPSink? Thank you very much! Hong Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070427/4b9bc756/attachment.html From finlayson at live555.com Fri Apr 27 12:27:22 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2007 12:27:22 -0700 Subject: [Live-devel] About the openRTSP source code In-Reply-To: <433437.41425.qm@web51104.mail.re2.yahoo.com> References: <433437.41425.qm@web51104.mail.re2.yahoo.com> Message-ID: >I start looking at the source code of openRTSP, and try to modify >the code to add SPS an PPS NAL units of H264 into saved file. To do this, you would modify (or extend) the "H264VideoFileSink" class. >By the way, what is the difference in use between H264VideoRTPSource >and H264VideoRTPSink? "H264VideoRTPSource" represents a source of H.264 RTP packets (i.e., coming in from the Internet). "H264VideoRTPSink" represents H.264 RTP packets that are being transmitted to the Internet. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Apr 27 12:42:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Apr 2007 12:42:21 -0700 Subject: [Live-devel] Cannot play an RTSP stream In-Reply-To: <772484426025194BAC0E4697D0B386D908042B@zmy16exm71.ds.mot.com> References: <772484426025194BAC0E4697D0B386D908042B@zmy16exm71.ds.mot.com> Message-ID: >I downloaded live55MediaServer from live555.com and ran it on my >linux system. I downloaded live source code and built it according >to steps given in >http://www.live555.com/liveMedia/#config-unix > >I downloaded Mplayer and built it. > >When i try to play an rtsp file, i get an error: Here is the complete log: > >[root at pclin518 bin]# ./mplayer rtsp://10.232.67.150:8554/dvb_sub.mpeg >MPlayer 1.0rc1-4.1.0 (C) 2000-2006 MPlayer Team >CPU: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz (Family: 6, >Model: 15, Step >ping: 6) >CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 >Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 > >Playing rtsp://10.232.67.150:8554/dvb_sub.mpeg. >Resolving 10.232.67.150 for AF_INET6... >Couldn't resolve name for AF_INET6: 10.232.67.150 >Connecting to server 10.232.67.150[10.232.67.150]: 8554... >connect error: Connection refused >Resolving 10.232.67.150 for AF_INET6... >Couldn't resolve name for AF_INET6: 10.232.67.150 >Connecting to server 10.232.67.150[10.232.67.150]: 8554... >connect error: Connection refused >File not found: '10.232.67.150:8554/dvb_sub.mpeg' >Failed to open rtsp://10.232.67.150:8554/dvb_sub.mpeg. > > >Exiting... (End of file) > >Am I doing something wrong? First, for "live555MediaServer" to be able to stream your file, its name cannot end with ".mpeg". If your file is a MPEG Program Stream file, then it's name must end with ".mpg" (not ".mpeg"). However, if (as seems likely from the name "dvb_sub") it is actually a MPEG *Transport* Stream file, then you must rename it to "dvb_sub.ts", before you will be able to stream it. Second, the "connection refused" error means that either - 10.232.67.150 is not the real IP address of the server (that is running "live555MediaServer"). (Perhaps you have a NAT box in the middle??), or - You are not actually running "live555MediaServer" on your server machine. Also, I recommend using VLC as your media player client rather than MPlayer. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070427/690d0606/attachment.html From ilya77 at gmail.com Sun Apr 29 04:53:44 2007 From: ilya77 at gmail.com (ilya77 at gmail.com) Date: Sun, 29 Apr 2007 14:53:44 +0300 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: <3cc3561f0704251443r778e1b0en9cf2ef7a9038ef37@mail.gmail.com> References: <3cc3561f0704251443r778e1b0en9cf2ef7a9038ef37@mail.gmail.com> Message-ID: Hi all, We've eliminated the NAT/ATM from the equation, and tried streaming the MPEG-2 TS over UDP (connecting the viewing PC directly to an ADSL line), and it did improve the sittuation dramatically, however, we sill have around 0.3- 0.7% packet loss over the WAN which results in video smearing here and there, and audio glitches (which are worse than video smearing because they are easily identified by ear and are more disturbing). We are wondering if either TS or RTP provide some means of forward error correction, since this rate of lost packets is normal over the public Internet, and from what we can tell the player (VLC) can not deal with those errors (and conceal them from the viewer). We are trying to find some information regarding embedding FEC information into the transport stream (as far as we understand it provides at least a container for error correction data), yet with no success. Any ideas? Many thanks, Ilya On 4/26/07, Morgan T?rvolt wrote: > > > Also, your email says you are using ATM (Asynchronous Transfer > Mode?). I > > check this on wikipedia, and notice that the data must be divided into > very > > small cells for delivery. It seems like ATM is a protocol for > > time-sensitive data, like VoIP. RTP also is designed to meet special > > timing needs of the data. Could there be a problem combining these two > > time-sensitive protocols? "If a circuit is exceeding its traffic > contract, > > the network can either drop the cells or mark the Cell Loss Priority > (CLP) > > bit (to identify a cell as discardable further down the line)." The RTP > > delivery can be somewhat bursty, so maybe you need to check your ATM > > contract and make sure you have the correct one (VBR maybe?) one? > > ATM is just a transport layer, as Ethernet, SDH and others. ATM is > usually used in for example ADSL connections. That the packet size is > 155 (or something like that) is not obvious, or even visible, to the > end hardware. It sees only an ordinary Ethernet link. > ATM is not very suited to do anything really. It is like a duck, it > can swim, fly and make sound, but does neither extremely well. For > extremely time sensitive data one uses SDH, which even keeps the > original input clock through the links. For time insensitive data one > uses Ethernet. ATM is very good at prioritizing traffic though, and it > could sound like the Ethernet packets are given a low priority, > possibly due to the fact that it is UDP. I have experienced this > before, and the configuration of a Ethernet card in one of the nodes > was to blame. It did not keep it's config due to hardware failure. In > your case this should be configurable in the ATM nodes, or management > software. > > As a "most likely" option, I would have to opt for bandwidth problem. > I have spent too many hours saying that it is not so on ATM networks > before. Check that your VCs and VPs are set up correctly, and try > transmitting TCP and UDP data from other sources than live. VLC stream > output would be a good place to start I believe. > > I agree with Ross here. You say it works well without the ATM, but not > with it. The reason for the problems is then too obvious. As there are > literally thousands of users of this software, I do believe that the > way it handles the Ethernet part works according to standard (unless > your OS or some configurations therein is to blame). One should not > make custom fixes to allow for broken hardware or configuration. In > this case "your network" seems like a good term, as most of the other > networks seems to work just fine. > > -Morgan- > _______________________________________________ > 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: http://lists.live555.com/pipermail/live-devel/attachments/20070429/e0998e46/attachment.html From l1436636 at yahoo.com Sun Apr 29 17:46:05 2007 From: l1436636 at yahoo.com (hong liu) Date: Sun, 29 Apr 2007 17:46:05 -0700 (PDT) Subject: [Live-devel] About the openRTSP source code Message-ID: <521302.36565.qm@web51109.mail.re2.yahoo.com> >>I start looking at the source code of openRTSP, and try to modify >>the code to add SPS an PPS NAL units of H264 into saved file. >To do this, you would modify (or extend) the "H264VideoFileSink" class. May I ask the reason why the openRTSP program doesn't save received SPS and PPS NAL units of H.264 into a local video file? Thank you so much! Hong Hong Liu ------------------------------ --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070429/ec397bf3/attachment.html From finlayson at live555.com Sun Apr 29 20:02:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 29 Apr 2007 20:02:15 -0700 Subject: [Live-devel] About the openRTSP source code Message-ID: > >>I start looking at the source code of openRTSP, and try to modify >>>the code to add SPS an PPS NAL units of H264 into saved file. > >>To do this, you would modify (or extend) the "H264VideoFileSink" class. > >May I ask the reason why the openRTSP program doesn't save received >SPS and PPS NAL units of H.264 into a local video file? Because the code wasn't written to do this. Note that these NAL units aren't part of the RTP stream, but are instead sent as an encoded string in the stream's SDP description. However, there exists a function ("MediaSubsession:: fmtp_spropparametersets()()") to access this string, and another function ("parseSPropParameterSets()") to decode this string into binary data - which you could, if you wished, write to a file. Sometime in the future, I might update the "H264VideoFileSink" class to do this itself.... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070429/079f0e2d/attachment.html From thomas at apestaart.org Mon Apr 30 09:09:05 2007 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 30 Apr 2007 18:09:05 +0200 Subject: [Live-devel] linking RTCP RR and RTSP sessions Message-ID: <1177949345.28381.80.camel@level.fluendo.lan> I was wondering exactly what the correct way is to relate RTCP RR reports to RTSP sessions on a server. I would like to know because, if I understand the RFC's correctly, an RTSP server MAY use any "wellness" information from clients (for example, RTCP RR packets) to keep the RTSP session alive. AFAICT, most mobile phones do not do keepalive on the RTSP layer, so an RTSP server has the need to tie RTCP RR packets to the RTSP sessions. (If I am wrong at this point, please do correct me, this stuff eats my brain when I think about it) The RTCP RR reports only provide the server with: - the client's (apparent) IP address (possibly changed through NAT) - the outgoing client UDP port from which these RTCP reports get sent (which I assume could have been changed through NAT) - the incoming server UDP port on which the server receives RTCP reports - the client's SSRC Of these, only the client's IP address was communicated to the RTSP server; the server knows which incoming UDP/RTCP port it asked the client to send to. I see the following options for the server to be able to map RTSP sessions to RTCP RR reports: - The server allocates a unique rtp and rtcp reception port for each RTSP session; this allows the server to id RTCP RR reports based on the incoming RTCP port. - The server uses the same rtp/rtcp reception port for each new RTSP session from a not-yet-known IP; if the same IP does a new session request, the server bumps rtp/rtcp reception ports. - The server uses the same rtp/rtcp reception port for everyone; it pretends that there is one session per IP. The first solution has the huge disadvantage that the server is limited to about 30k clients, given the number of ports it can receive on. Not to mention that select() would go out the window for checking activity :) The second solution is a little less greedy with ports, but harder to code. The third one seems wrong to me. I was wondering what the behaviour is of the live555 libraries. Anyone know ? Thanks Thomas From xcsmith at rockwellcollins.com Mon Apr 30 11:41:13 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 30 Apr 2007 13:41:13 -0500 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss Message-ID: Hi all, We've eliminated the NAT/ATM from the equation, and tried streaming the MPEG-2 TS over UDP (connecting the viewing PC directly to an ADSL line), and it did improve the sittuation dramatically, however, we sill have around 0.3 - 0.7% packet loss over the WAN which results in video smearing here and there, and audio glitches (which are worse than video smearing because they are easily identified by ear and are more disturbing). We are wondering if either TS or RTP provide some means of forward error correction, since this rate of lost packets is normal over the public Internet, and from what we can tell the player (VLC) can not deal with those errors (and conceal them from the viewer). We are trying to find some information regarding embedding FEC information into the transport stream (as far as we understand it provides at least a container for error correction data), yet with no success. Any ideas? Many thanks, Ilya Re: Are you watching the video in real time or just recording it? you could use openRTSP to record the video stream and see if it helps at all to do this. in openRTSP you can adjust the amount of time to wait for a late packet. I'm not sure how much difference it would make. Have you tried going back to TCP streaming? If a packet is too late, it will be discarded, but if you are only doing a recording and not trying to watch the video real time, then you can wait a little longer for late packets. I don't think the TS format provides any sort of other error correction, aside from having very small packets to stop packet loss from having a dramatic effect on the system. I do not believe there is any way to recalculate the missing data from nearby data, if that's what you are asking. From finlayson at live555.com Mon Apr 30 12:19:28 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Apr 2007 12:19:28 -0700 Subject: [Live-devel] linking RTCP RR and RTSP sessions In-Reply-To: <1177949345.28381.80.camel@level.fluendo.lan> References: <1177949345.28381.80.camel@level.fluendo.lan> Message-ID: >I was wondering exactly what the correct way is to relate RTCP RR >reports to RTSP sessions on a server. I would like to know because, if >I understand the RFC's correctly, an RTSP server MAY use any "wellness" >information from clients (for example, RTCP RR packets) to keep the RTSP >session alive. Our RTSP server implementation already implements this; you don't need to write any new code to do this. Note the "reclamationTestSeconds" parameter (default value: 45) to "RTSPServer::createNew()". This tells the server how long to wait for activity (RTSP commands, *or* RTCP "RR" packets) to come from each client, before it terminates the session. The default value of 45 seconds should be sufficient for almost every stream; you should not need to change it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Apr 30 12:49:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Apr 2007 12:49:39 -0700 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: References: Message-ID: >We are wondering if either TS or RTP provide some means of forward error >correction No, not at present. However, there is ongoing work in the IETF (the "FECFRAME" working group) towards standardizing FEC on media streams. (This FEC would occur just above the UDP level, so could be applied to raw-UDP Transport Streams, as well as RTP streams (of any payload type).) >Re: Are you watching the video in real time or just recording it? you >could use openRTSP to record the video stream and see if it helps at all to >do this. in openRTSP you can adjust the amount of time to wait for a late >packet. Not really. If incoming packets are not being reordered on the network, then the RTP reception code (regardless of the application) will wait indefinitely for RTP packets to arrive; there is no concept of a 'late' packet. If packets *are* being reordered on the network (a rare occurrence), then the code will wait up to a certain time (default: 100ms) for a 'late' packet to arrive. You can change this time, but note, once again, that it is relevant only if packets are arriving out of order - which rarely happens. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ilya77 at gmail.com Mon Apr 30 13:33:40 2007 From: ilya77 at gmail.com (ilya77 at gmail.com) Date: Tue, 1 May 2007 00:33:40 +0400 Subject: [Live-devel] Live555 MPEG2 Transport Stream packet loss In-Reply-To: References: Message-ID: On 4/30/07, Ross Finlayson wrote: > > >We are wondering if either TS or RTP provide some means of forward error > >correction > > No, not at present. However, there is ongoing work in the IETF (the > "FECFRAME" working group) towards standardizing FEC on media streams. > (This FEC would occur just above the UDP level, so could be applied > to raw-UDP Transport Streams, as well as RTP streams (of any payload > type).) > > >Re: Are you watching the video in real time or just recording it? you > >could use openRTSP to record the video stream and see if it helps at all > to > >do this. in openRTSP you can adjust the amount of time to wait for a > late > >packet. > > Not really. If incoming packets are not being reordered on the > network, then the RTP reception code (regardless of the application) > will wait indefinitely for RTP packets to arrive; there is no concept > of a 'late' packet. > > If packets *are* being reordered on the network (a rare occurrence), > then the code will wait up to a certain time (default: 100ms) for a > 'late' packet to arrive. You can change this time, but note, once > again, that it is relevant only if packets are arriving out of order > - which rarely happens. > -- We are currently using VLC to view the media stream, and our goal is to set up a server which is capable of streaming to any RTSP / MPEG-2 TS capable player, so in essence - we are using live555 media *server* capabilities, but not client capabilities (unless VLC uses portions of the live555 project). We are trying to stream a pre-recorded transport stream file, and from what we see on the sniffer dump, packet reordering does *not* occur on the network. Regarding error correction - as far as I can tell, the transport stream does provide a container for error correction information, but it is somewhat opaque and transport-dependant, which led me to hoping that RTP might provide some method of forward error correction... Am I correct that apart from trying to resolve network infrastructure problems (which might be impossible since there are too many instances involved in the process) we have no means to achieve reliable media delivery? Many thanks, Ilya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070430/3613e2ce/attachment.html