From yamini.s at europlex.in Thu May 1 03:06:41 2008 From: yamini.s at europlex.in (Yamini S. [EPLX - DCC]) Date: Thu, 1 May 2008 15:36:41 +0530 Subject: [Live-devel] tearDownStreams() References: <002c01c8aac2$7d310100$77930300$@com> Message-ID: <6872DF21E3D09046BDF172721037F4FB387AFD@SBTEXCHANGEDB.sbtdats.com> Can u tell me how did get a player to receive the streams Thanks & Regards, S.Yamini Programmer R&D Siemens Building Technologies Pvt. Ltd. ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Nikhil Naik Sent: Wednesday, April 30, 2008 6:33 PM To: live-devel at ns.live555.com Subject: [Live-devel] tearDownStreams() Hi Ross, I am working with a MJPG streamer and a player to receive the stream. Both are based on the LIVE555 libraries. When I use it over the LAN the server seems to see OPTIONS - TEARDOWN requests. But when I stream over the internet using the -t (TCP) parameter the server Doesn't seem to receive the TEARDOWN. I can receive the stream but when I disconnect The server is still servicing a client even though none are connected Note (sendRequest(cmd, "TEARDOWN")) is sucessfully executed In the RTSPClient class. Any ideas what might be going on? Any suggestions? Nikhil Naik This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. You may not copy, disclose or use the contents in any way. SBTPL does not guarantee integrity of this communication nor that this communication is free of viruses, interceptions or interference. This communication does not create or modify any contract, and unless otherwise stated, is not intended to be contractually binding. Views or opinions expressed in this e-mail message are those of the author only. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080501/73c6c7d3/attachment.html From manas_ec007in at yahoo.co.in Thu May 1 04:00:13 2008 From: manas_ec007in at yahoo.co.in (manas lenka) Date: Thu, 1 May 2008 12:00:13 +0100 (BST) Subject: [Live-devel] About SIP implementations in LIVE555 media... Message-ID: <401565.14980.qm@web8908.mail.in.yahoo.com> Hi, Shaswata.. Thanks for your reply and suggestions. I have some doubts: Q1: Is there any SIP test programme so that I can use it. Q2: You told me to store the encoded data in some in-memory data-structure what this actually mean. Are you talking about an buffer or queue. Q3: How the synchronization between the caller and callee will be taken care ? Whether I have to write my custom programme for this or LIVE 555 media takes care of this. THANKS In ADVANCE MANAS --------------------------------- Meet people who discuss and share your passions. Join them now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080501/80c2e8df/attachment.html From alex.tarter at ultra-scs.com Thu May 1 07:03:16 2008 From: alex.tarter at ultra-scs.com (Alex Tarter) Date: Thu, 1 May 2008 15:03:16 +0100 Subject: [Live-devel] Program flow question Message-ID: I am new to developing using live555 so please excuse any obvious questions! I'm trying to stream JPEG images over RTP, so I've modified the Elphel example to instead of getting a frame from a camera to read and send the same JPEG image from file. Effectively just sending the same image over and over again. Once I can do this I'll move on to generating streaming jpeg frames. The program compiles and seems to run (though wireshark says all the packets are malformed!), though the timing is constant at 250 frames per second!! No matter what frame rate I give it as an initial argument. I imagine it is because there is no delay function in my code. At the moment the 'fTimePerFrame' is set in the constructor for ElphelJPEGDeviceSource but not used anywhere. Within the doEventLoop() what is telling the process to only call doGetNextFrame() regularly (5 times per second say) rather than continuously? Should the delay function go in the startCapture() function or the doGetNextFrame() or is there a variable I need to set when adding the source to the environment taskscheduler? Thanks, Alex Alex Tarter Ultra Electronics Sonar & Communication Systems Tel: +44 (0)20 8813 4527 Mobile: +44 (0)772 018 2267 www.ultra-electronics.com This e-mail from Ultra Electronics Limited and any attachments to it are confidential to the intended recipient and may also be privileged. If you have received it in error please notify the sender and delete it from your system. If you are not the intended recipient you must not copy it or use it for any purpose nor disclose or distribute its contents to any other person. All communications may be subject to interception or monitoring for operational and/or security purposes. Please rely on your own virus checking as the sender cannot accept any liability for any damage arising from any bug or virus infection. Ultra Electronics Limited is a company registered in England and Wales, registration number 2830644. The address of its registered office is 417 Bridport Road, Greenford, Middlesex, UB6 8UA. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080501/9c84ed1e/attachment-0001.html From finlayson at live555.com Thu May 1 17:33:26 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 May 2008 17:33:26 -0700 Subject: [Live-devel] Program flow question In-Reply-To: References: Message-ID: >I imagine it is because there is no delay function in my code. At >the moment the 'fTimePerFrame' is set in the constructor for >ElphelJPEGDeviceSource but not used anywhere. Yes, because the original code read from a live source (a camera), it was not necessary to set the "fDurationInMicroseconds" variable in your "doGetNextFrame()" function. (By not setting this variable, it remains at its default value of 0.) However, because you are now reading from a pre-recorded file - rather than from a live source - you must now set that variable. You should add the following line to your "ElphelJPEGDeviceSource::deliverFrameToClient()" function, sometime before the "envir().taskScheduler().scheduleDelayedTask()" call: fDurationInMicroseconds = fTimePerFrame; >Within the doEventLoop() what is telling the process to only call >doGetNextFrame() regularly (5 times per second say) rather than >continuously? The "fDurationInMicroseconds" variable (which is ultimately used by "MultiFramedRTPSink", when rescheduling the next outgoing RTP packet after sending one). -- 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/20080501/d7f42b49/attachment.html From luwei at tju.edu.cn Sat May 3 09:07:35 2008 From: luwei at tju.edu.cn (luwei at tju.edu.cn) Date: Sun, 04 May 2008 00:07:35 +0800 Subject: [Live-devel] live555 is great, but I need help for recording WMV streams. Message-ID: <409830855.08124@tju.edu.cn> Hi, I have an urgent task that I should download and record the WMV files from Windows Media Server via RTSP. I have reported in the mailing-list that when using openRTSP to get a WMV stream from windows media server, I would get a file that is different with the original one on the server and cannot be decoded. (I settled up the server and put a wmv file on it for comparison.) I did further experiments and found out that the reason lied in the server side: Experiment procedures: I used a windows software named HiDownload to save a WMV file, meanwhile, I captured the ethernet packets with Ethereal. I also captured packets when playing the RTSP stream with VLC, as well as receiving the stream with openRTSP. (I have not tested windows media player yet.) Results: 1. Although the wmv file saved by HiDownload can be decoded correctly, it is not the same as the original file. 2. The captured packets of VLC, openRTSP and HiDownload are IDENTICAL, but HiDownload adds some stuff bytes when saving the packets. In other words, HiDownload does more than justing receiving the stream. (For VLC, it will demux and decode the received packets with no problem.) Conclusion: 1. live555 library and openRTSP are great and fully compliant to RTSP protocol. Thanks, Ross. 2. It is ugly and difficult to deal with the received RTSP packets according to its format, especially that Microsoft's specification for WMV file format is not clear enough. If anyone could offer help, I will quite appreciate it. From luwei at tju.edu.cn Sun May 4 04:30:03 2008 From: luwei at tju.edu.cn (luwei at tju.edu.cn) Date: Sun, 04 May 2008 19:30:03 +0800 Subject: [Live-devel] Save WMV file from Windows Media Server via RTSP: Almost done. Message-ID: <409900603.31017@tju.edu.cn> Hi, openRTSP can be used to save wmv stream on windows media server, with some tricks. The procedure is: /openRTSP rtsp://... -S 4 You must get the header of wmv file from SDP data first (pls refer to VLC source code). The recorded file like audio-x-asf/video-x-asf contains the data packets of the wmv file. However, just to splice the header and the video-x-asf together cannot get a decodable wmv file. (Maybe some server has different settings and you can succeed in doing so. At least, I have suffered enough doing that.) The most important trick here is that you should make the length of data packet equal to 1444 by stuffing some bytes to the end of it. I have just tested one file and seen the video displayed. I am not sure that the procedure proposed here works for most cases. Thank u, Ross. Your tools are very reliable. From kapo at acroid.com Sun May 4 05:21:07 2008 From: kapo at acroid.com (Eno Kapo) Date: Sun, 4 May 2008 14:21:07 +0200 Subject: [Live-devel] rtmp to rtsp transforming -transcoding live streaming ?! In-Reply-To: <409900603.31017@tju.edu.cn> References: <409900603.31017@tju.edu.cn> Message-ID: <007701c8ade1$55bb6350$013229f0$@com> Hi Anyone tested if it possible to transform-transcode a live stream from rtmp- flash live stream on rtsp ?! so from rtmp://..../webcam on rtsp://.../webcam Any tips, suggestions or experience ?! Thanks Eno -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of luwei at tju.edu.cn Sent: dimanche 4 mai 2008 13:30 To: live-devel at ns.live555.com Subject: [Live-devel] Save WMV file from Windows Media Server via RTSP: Almost done. Hi, openRTSP can be used to save wmv stream on windows media server, with some tricks. The procedure is: /openRTSP rtsp://... -S 4 You must get the header of wmv file from SDP data first (pls refer to VLC source code). The recorded file like audio-x-asf/video-x-asf contains the data packets of the wmv file. However, just to splice the header and the video-x-asf together cannot get a decodable wmv file. (Maybe some server has different settings and you can succeed in doing so. At least, I have suffered enough doing that.) The most important trick here is that you should make the length of data packet equal to 1444 by stuffing some bytes to the end of it. I have just tested one file and seen the video displayed. I am not sure that the procedure proposed here works for most cases. Thank u, Ross. Your tools are very reliable. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel __________ NOD32 3072 (20080503) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com From ken.seo at gmail.com Mon May 5 07:33:28 2008 From: ken.seo at gmail.com (Ken Seo) Date: Mon, 5 May 2008 10:33:28 -0400 Subject: [Live-devel] BasicTaskScheduler is not handling err 10038 In-Reply-To: References: <5e008ff40804300846y48afacccn8112d96f84c0a407@mail.gmail.com> <5e008ff40804301515n2a25b1a3uc6bcd4e707e04850@mail.gmail.com> Message-ID: <5e008ff40805050733v69241293r32b075199453210f@mail.gmail.com> Hi Ross, So, here is what I found, "WSAGetLastError()" returns WSAENOTSOCK when turnOffBackgroundReadHandling was not called as many times as turnOnBackgroundReadHandling is called. So, my problem was happening only on RTP over TCP, as turnOnBackgroundReadHandling is called twice for RTCP handling and turnOffBackgroundReadHandling was called only once when clientsession is deleted. in OnDemandMediaSubsession.cpp, startPlaying method (line 425), RTCPInstance::createNew(..) will call turnOnBackgroundReadHandling as a part of RTCPInstance construction. and then, if it's RTCP over TCP, addStreamSocket is called, which will call turnOnBackgroundReadHandling again (for the same socket) if (dests->isTCP) { .. fRTCPInstance->addStreamSocket(..) in RTCP.cpp void RTCPInstance::addStreamSocket(int sockNum, unsigned char streamChannelId) { // Add the RTCP-over-TCP interface: fRTCPInterface.setStreamSocket(sockNum, streamChannelId); // Turn on background reading for this socket (in case it's not on already): TaskScheduler::BackgroundHandlerProc* handler = (TaskScheduler::BackgroundHandlerProc*)&incomingReportHandler; fRTCPInterface.startNetworkReading(handler); } So, my quickest fix was to put the following line void RTCPInstance::addStreamSocket(int sockNum, unsigned char streamChannelId) { * // Turn off the default background read handling created along with RTCPInstance fRTCPInterface.stopNetworkReading(); * // Add the RTCP-over-TCP interface: fRTCPInterface.setStreamSocket(sockNum, streamChannelId); // Turn on background reading for this socket TaskScheduler::BackgroundHandlerProc* handler = (TaskScheduler::BackgroundHandlerProc*)&incomingReportHandler; fRTCPInterface.startNetworkReading(handler); } I'm not 100% sure why you have to call "turnOnBackgroundReadHandling" twice for RTP over TCP, but it seems like "turnOnBackgroundReadHandling" should be called after "fRTCPInterface.setStreamSocket(sockNum, streamChannelId)" to handle RTCP over TCP correctly. --> Also I was just wondering, isn't fRTCPInterface supposed to be fRTPInterface, since it is actually an instance of RTPInterface, I know that I don't fully understand live555 code at the moment, so, if what I explained above does not make any sense to you then please let me know, Best Regards, Ken Seo On Wed, Apr 30, 2008 at 9:01 PM, Ross Finlayson wrote: > >Windows error 10038 is "WSAENOTSOCK", and typically happens when an > >application is trying to do some socket operation on non-socket or the > >socket that has already been closed, (at least that's my > >understanding..) > >I was getting this error, from the line in the BasicTaskScheduler.cpp > >(build 2008-04-03) > > > > int err = WSAGetLastError(); // err = 10038 > > > >And it only happens when RTSP server tries to delete clientSession due > >to livenessTimeout, (it doesn't happen when session gets closed by > >TEARDOWN request). > > That's odd, because - in each case - the "RTSPClientSession" > destructor will get called, and this should be removing its socket > from the set of active sockets, via the call to > envir().taskScheduler().turnOffBackgroundReadHandling(fClientSocket); > on line 271 of "RTSPServer.cpp". > > So I wonder why this isn't working for you. > > Please let us know if you can find out anything more about this issue. > -- > > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ambra.Cristaldi at elsagdatamat.com Mon May 5 08:30:40 2008 From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra) Date: Mon, 5 May 2008 17:30:40 +0200 Subject: [Live-devel] Connections not closed Message-ID: <268315E5844A704AB431589863FE8EEF0125DAC7@els00wmx04.elsag.it> Hi, Some days ago I read the following thread http://www.mail-archive.com/live-devel at lists.live555.com/msg01747.html . I have a similar problem and I was wondering if it was a problem concerned the RTSP- protocol. It's important to say that I *don't use* the command "-t" to request TCP connection. I know that, typically, RTSP uses TCP as its transport protocol, on port 554. All I do is running my openRTSP-project on windows platform and observing the state of the network. The result is that: - The Teardown operation is executed perfectly: I obtain the correct reply from the client (RTSP/1.0 200 ok). But during the teardown- request I find a problem in server request, concerning a possible "TCP checksum offload" (observed it with Wireshark program). - After this operation, my client and server communicate between them on TCP protocol to close connection (I suppose), but I still find the same problem about the checksum, still on the server-side. - Then, I control the state of the network using the command "netstat -na" and find that a connection between client and server on TCP remains in "TIME_WAIT" state, for a few minutes... So, is this behaviour normal/correct? If not, what could be the problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.boschi at totalwire.it Mon May 5 09:37:00 2008 From: s.boschi at totalwire.it (Sigismondo Boschi) Date: Mon, 05 May 2008 18:37:00 +0200 Subject: [Live-devel] Connections not closed In-Reply-To: <268315E5844A704AB431589863FE8EEF0125DAC7@els00wmx04.elsag.it> References: <268315E5844A704AB431589863FE8EEF0125DAC7@els00wmx04.elsag.it> Message-ID: <481F37AC.1020006@totalwire.it> > - The Teardown operation is executed perfectly: I obtain the > correct reply from the client (RTSP/1.0 200 ok). But during the > teardown- request I find a problem in server request, concerning a > possible ?TCP checksum offload? (observed it with Wireshark program). Ciao Ambra, This is quite typical with wireshark - here is the official explanation: http://wiki.wireshark.org/TCP_checksum_offload So simply don't care of it: I think TCP would not work at all without the correct checksums... or maybe a broken card/config is your problem (but then, it would be curious how the communication is initiated)! > - Then, I control the state of the network using the command > ?netstat ?na? and find that a connection between client and server on > TCP remains in ?TIME_WAIT? state, for a few minutes? > > So, is this behaviour normal/correct? If not, what could be the problem? TIME_WAIT is normal: after a connection is closed TCP stays in time-wait from (30?) seconds to a couple of minutes (depends on the platform) to make sure all the stuff related to the connection is gone on both sides. You do not need to care of it except the number of TIME_WAITs become enormous, that is, you open/close connections very quickly (once I did hit the limit just with a 1000+ nodes clusters with one node connecting to all the others with ssh, repetitively...) So, after all, what is the problem? What isn't working - since you are not using "-t"? Regards, Sigismondo Boschi -- ------------------------------------------------------------------ Sigismondo Boschi, PhD TotalWire S.r.l. s.boschi at totalwire.it http://www.totalwire.it cell: +39 346 7911896 tel: +39 051 302696 -------------- next part -------------- A non-text attachment was scrubbed... Name: s_boschi.vcf Type: text/x-vcard Size: 275 bytes Desc: not available URL: From sriramsm at yahoo.com Mon May 5 10:45:39 2008 From: sriramsm at yahoo.com (Sriram Murthy) Date: Mon, 5 May 2008 10:45:39 -0700 (PDT) Subject: [Live-devel] Problem with H264 RTP streams Message-ID: <204367.15798.qm@web32007.mail.mud.yahoo.com> Hi, I am using vlc on linux to play a H264 (1080p) RTP stream using the sdp file that I have attached with this email. However I keep getting the following messages - -------------------------------------------------- [00000328] live555 demuxer debug: tk->rtpSource->hasBeenSynchronizedUsingRTCP() MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (65536). 62 bytes of trailing data will be dropped! [00000328] live555 demuxer debug: lost 62 bytes [00000328] live555 demuxer debug: increasing buffer size to 131072 MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (131072). 56 bytes of trailing data will be dropped! [00000328] live555 demuxer debug: lost 56 bytes [00000328] live555 demuxer debug: increasing buffer size to 262144 [00000349] faad decoder warning: Quantised value out of range --------------------------------------------- and neither the video nor the audio is being rendered. Can somebody please let me know what could be the problem?. Also, how can I change the default maxsize of the buffer? Thanks and regards, Sriram ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- A non-text attachment was scrubbed... Name: sdp_1080p.sdp Type: application/sdp Size: 532 bytes Desc: 2544462513-sdp_1080p.sdp URL: From ratin3 at gmail.com Mon May 5 11:42:04 2008 From: ratin3 at gmail.com (Ratin) Date: Mon, 5 May 2008 11:42:04 -0700 Subject: [Live-devel] SDP question Message-ID: <5c70701a0805051142l7431c7b4j13d83484fa7fc2a@mail.gmail.com> If I have a live stream that is being recorded, can the server send t="