From finlayson at live555.com Sat May 1 23:53:57 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 1 May 2010 23:53:57 -0700 Subject: [Live-devel] SegmentQueue::enqueueNewSegment() overflow In-Reply-To: References: Message-ID: >First, let me say that I'm totally new to Live555 and multimedia >streaming in general. I'm planning to build an on-demand RTSP server >for streaming WAV and/or MP3 files via RTP unicast to an RTSP client. > >I've built and tried the TestOnDemandRTSPServer in the testProgs >directory. Streaming a WAV file works flawless, but when streaming a >MP3 file I get the error > >SegmentQueue::enqueueNewSegment() overflow > >which is generated in MP3ADU.cpp. Thanks for the bug report (and my apologies for not reponding sooner; I've been busy traveling (and, more recently, doing a lot of work on improving the "RTSPClient" implementation)). I'll be looking into this bug (using your MP3 test file) shortly, and will send another message to the list once I have a fix. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun May 2 00:53:08 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 2 May 2010 00:53:08 -0700 Subject: [Live-devel] Streaming H264 difficulties In-Reply-To: <009701cada58$6f22a880$337ba8c0@YARON> References: <009701cada58$6f22a880$337ba8c0@YARON> Message-ID: (My apologies for the delay in responding to this message.) >I am working on a RTSP RTP-over-TCP H264 streaming application from >a live HW-based encoder. >I have implemented MyDeviceSource, MyH264VideoStreamFramer, >H264DeviceMediaSubsession and MyH264App based on >testOnDemandRTSPServer. In general the application works and I get >the live stream. >The intended viewer application is VLC on a remote machine in the >same LAN, where bandwidth is a non-issue. > >I've encountered 2 obstacles that have been giving me a hard time: >1. "Glitches" in the video output. After every (quite small) amount >of frames the video "glitches" and I get block artifacts, and frames >that seem to jump back in time. From playing around with the >presentation times, I thought it might be related to this. Possibly - see below. >My approach to fPresentationTime is to set it to gettimeofday() >every GOP (i.e. SPS/PPS frames), and increment by 1000000/FPS for >every encoded frame. Does your H.264 stream contain "B" frames? If so, then note that the presentation times should *not* be monotonic increasong, and therefore your method of setting "fPresentationTime" is incorrect. If you stream does contain "B" frames, then I suggest that you look at the "MPEG4VideoStreamDiscreteFramer" code for a model of how to properly set "fPresentationTime" for H.264 frames. > The encoder encodes frame by frame only. >When I use openRTSP as the client, the video file is saved >perfectly, which no glitches. That is not surprising, because "openRTSP" does not care about presentation times; it just records the incoming data that it sees. > 2. The streaming server (OS is Linux2.6) is also used for other >cpu-intensive processes. This is a requirement. The machine is >practically constantly at 100% cpu usage. However, it practically >does not use any network resources. >When this is the situation, the video glitches become overwhelming, >and it seems the client has a very hard time handling the stream and >sometimes even disconnects. What happens when you run your server machine *without* these other CPU-intensive processes? It sounds like you may just have an underpowered computer... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.trotti at elsagdatamat.com Mon May 3 01:02:15 2010 From: matteo.trotti at elsagdatamat.com (Trotti Matteo) Date: Mon, 3 May 2010 10:02:15 +0200 Subject: [Live-devel] R: "GET_PARAMETER" as a client 'liveness' indicator In-Reply-To: References: Message-ID: You have to schedule a dummy task which get called at a given time interval inside the EventLoop. Create a task where you will just issue a GET_PARAMETER command rtspClient->getMediaSessionParameter and after that, simply re-schedule the task itself with a given time interval env->taskScheduler().scheduleDelayedTask. Now just call the task for the first time before starting the EventLoop. Bye, Matteo Trotti Videosurveillance Lab Elsag Datamat Spa Genova, Italy Da: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Per conto di St?phane Le Jeune Inviato: luned? 26 aprile 2010 15.20 A: live-devel at ns.live555.com Oggetto: [Live-devel] "GET_PARAMETER" as a client 'liveness' indicator Hello, I read that openRTSP can send GET_PARAMETER as keepAlive (or client liveness indicator) but nothing in the source code show that (in RTSPClient.cpp). During our session, the timeout is sent by the video server in the RTSP SETUP response and catched by openRTSP, but nothing append then when the time expired. Why no behavior has been developped ? Is there any player that can be able to send GET_PARAMETER in place of RTCP "RR" packet ? Fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From galaxy at novosun.com Tue May 4 04:19:11 2010 From: galaxy at novosun.com (Kam Wai-ip) Date: Tue, 4 May 2010 19:19:11 +0800 Subject: [Live-devel] RTSP Client Timeout Message-ID: Hi, I am currently using livemedia as my rtsp client, however, I am suffering a problem, which the timeout parameter on the DescribeWithPassword and describeURL functions doesn't seems to work. Therefore when connection fail at start, the program will have to wait for a very long time. Can you think of why or have I done anything wrong. Thanks for your help Wai -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue May 4 12:32:43 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 May 2010 12:32:43 -0700 Subject: [Live-devel] RTSP Client Timeout In-Reply-To: References: Message-ID: > I am currently using livemedia as my rtsp client, however, I am >suffering a problem, which the timeout parameter on the >DescribeWithPassword and describeURL functions doesn't seems to >work. Therefore when connection fail at start, the program will have >to wait for a very long time. Can you think of why or have I done >anything wrong. Not really, unfortunately. I suggest tracing through those functions' implementation (in "liveMedia/RTSPClient.hh") to try to figure out what's going wrong. (However, a completely new implementation of "RTSPClient" is coming soon (hopefully within days). It might fix your problem.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From galaxy at novosun.com Tue May 4 19:03:35 2010 From: galaxy at novosun.com (Kam Wai-ip) Date: Wed, 5 May 2010 10:03:35 +0800 Subject: [Live-devel] RTSP Client Timeout In-Reply-To: References: Message-ID: Thx for your advice, good work Ross, really looking forward to test the new client. All The Best!! Wai On Wed, May 5, 2010 at 3:32 AM, Ross Finlayson wrote: > I am currently using livemedia as my rtsp client, however, I am suffering >> a problem, which the timeout parameter on the DescribeWithPassword and >> describeURL functions doesn't seems to work. Therefore when connection fail >> at start, the program will have to wait for a very long time. Can you think >> of why or have I done anything wrong. >> > > Not really, unfortunately. I suggest tracing through those functions' > implementation (in "liveMedia/RTSPClient.hh") to try to figure out what's > going wrong. > > (However, a completely new implementation of "RTSPClient" is coming soon > (hopefully within days). It might fix 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Fri May 7 09:28:39 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Fri, 7 May 2010 09:28:39 -0700 Subject: [Live-devel] Crash in RTSPServer.cpp In-Reply-To: References: Message-ID: On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson wrote: > > It would be nice to find a simple, repeatable sequence of client operations > that cause the crash. E.g., does crash ever happen if there are two > complete "DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN" sequences in order (i.e., > not overlapping), or does it occur only when two such sequences overlap? > Once you've found a repeatable situation that causes the crash, then you > could also test with RTP-over-UDP, and with "reuseFirstSource" set to False. Okay, I did more testing. Definitely the issue is overlapping DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN sequences. And for me, the problem was exacerbated by the fact that my client would connect to the server _twice_ (once to fetch media types, then a TEARDOWN, and again to start pulling media). I changed it so my code connects a single time and I can no longer reproduce the crash. So I think there is a bug in there somewhere, and it definitely involves overlapped sequences like that. I did try to isolate it with mediaServer and openRTSP, but...haven't had a lot of luck. I'll let you know if I find out anything else. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amor_massi at yahoo.fr Sun May 2 09:23:20 2010 From: amor_massi at yahoo.fr (amor massi) Date: Sun, 2 May 2010 16:23:20 +0000 (GMT) Subject: [Live-devel] multithreading an sending pause cmd Message-ID: <362255.19378.qm@web24203.mail.ird.yahoo.com> Hi; I am using multithreading, on the client?side,?to stream video from multiple servers. The main thread has an array CLIENTS[] of Clients. Each Client has its own Envirenment, TaskSchudeler and RTSPClient Object.? For each session with a server, this thread creates?2 other threads: ??? 1- one to establish the connexion and bloc on the doEventLoop. When receiving packets, this thread stores?them in a Queue. ??? 2- the other gets these packets and stores them in the main Queue of the main thread. This last one reconstracts the stream and plays it. The streaming works and I play the video?without probleme. But I have troubles to pause the streams. To pause the whole stream, I must pause each server stream by sending the pause cmd. I tried to send these requests by the main thread, and then by each thread on its client without success. In the two cases?I can pause only ONE session. Any idea? -------------- next part -------------- An HTML attachment was scrubbed... URL: From grs.tanya at gmail.com Wed May 5 04:24:31 2010 From: grs.tanya at gmail.com (Groysberg Tanya) Date: Wed, 5 May 2010 14:24:31 +0300 Subject: [Live-devel] Live555 support over SRTP Message-ID: Hi, At the to do list is task: "Add support for SRTP ('secure' RTP), and perhaps also RTSP-over-TLS." Do you intend to supply this feature any time soon. Or may be someone started to implement this feature? Thanks in advance, Tanya -------------- next part -------------- An HTML attachment was scrubbed... URL: From szterry at 21cn.com Thu May 6 00:09:51 2010 From: szterry at 21cn.com (Terry) Date: Thu, 6 May 2010 15:09:51 +0800 (CST) Subject: [Live-devel] How to get the RealRTSP.hh??PLz help~ Message-ID: <31160193.246451273129791955.JavaMail.root@webmail6> An HTML attachment was scrubbed... URL: From a.ricciardi at fastwebnet.it Thu May 6 09:22:07 2010 From: a.ricciardi at fastwebnet.it (Andrea Ricciardi) Date: Thu, 6 May 2010 18:22:07 +0200 Subject: [Live-devel] Problem with rtcp Message-ID: <245C9F372D5A4C37AE987B73EB4A90F0@pcandrea> Hi everybody, I developed an embedded application that creates one MP4 stream + one PCM stream from a camera and a microphone. I need to send them over the network using RTP. My application writes the 2 streams to 2 separate linux fifos, /fifo_video and /fifo_audio, so I simply modified the testMPEG4VideoStreamer and testWAVAudioStreamer to read from the fifos instead of the "test.*" files. Then I use vlc with an sdp file to receive the streams, but I only get a few random video and audio frames, with long periods with no video or audio. Moreover, If I modify the sdp file to receive only one stream, either the video or the audio one, everything works perfectly, no frame loss. So I suspected it could be a problem of audio - video synchronization, and tried to remove the rtpc creation from the test*Streamer applications (commented the RTCPInstance::createNew calls) and this way I can play both audio and video streams together in vlc without any problem (apart from the fact that of course they are 1-2 seconds out of sync). So the questions are: 1) is my setup ok or do I miss something? 2) Any idea about why the presence of the rtcp messages modify the vlc behavior in such a way that it can't play the video and audio streams? Thanks in advance, Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From chouhan.nishesh at gmail.com Fri May 7 03:35:26 2010 From: chouhan.nishesh at gmail.com (nishesh chouhan) Date: Fri, 7 May 2010 16:05:26 +0530 Subject: [Live-devel] rtsp proxy Message-ID: Hi Ross, I want to modify live555 code to work it as an RTSP proxy, please guide me what all would I require to do do we already have proxy support I think we dont. Many Thanks, Nishesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat May 8 00:01:30 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 May 2010 00:01:30 -0700 Subject: [Live-devel] How to get the RealRTSP.hh??PLz help~ In-Reply-To: <31160193.246451273129791955.JavaMail.root@webmail6> References: <31160193.246451273129791955.JavaMail.root@webmail6> Message-ID: >From the maillist live-devel, i know that this >file?iRealRTSP.hh?j didn't include in the LIVE55 >distribution. >But how and when will it distribute??And how >about the inactive source codes under the >"SUPPORT_REAL_RTSP"? The "REAL_RTSP" stuff was an old, only partially implemented (and non-standard) hack that we did for a client several years ago. It was never made part of the "LIVE555 Streaming Media" release, and all references to it have now been eliminated from the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat May 8 00:27:43 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 May 2010 00:27:43 -0700 Subject: [Live-devel] Live555 support over SRTP In-Reply-To: References: Message-ID: > >At the to do list is task: >"Add support for SRTP ('secure' RTP), and perhaps also RTSP-over-TLS." >Do you intend to supply this feature any time soon. Sorry, no. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat May 8 07:16:42 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 May 2010 07:16:42 -0700 Subject: [Live-devel] SegmentQueue::enqueueNewSegment() overflow In-Reply-To: References: Message-ID: >I've built and tried the TestOnDemandRTSPServer in the testProgs >directory. Streaming a WAV file works flawless, but when streaming a >MP3 file I get the error > >SegmentQueue::enqueueNewSegment() overflow > >which is generated in MP3ADU.cpp. The 'problem' here is the excessively 'VBR' nature of your input file, which was causing the code to run into the "SegmentQueueSize" limit. Increasing this limit from 10 to 20 eliminates the error. (This will be fixed in the next release of the software.) > While increasing SegmentQueueSize obviously helps in avoiding this >error, there are still a lot of "gaps" in the playback. The extreme 'VBR-ness' of your input file might be causing some difficulties elsewhere. If you're still having problems with this file, you might want to consider reencoding it using less aggressive VBR - if you can. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat May 8 23:23:31 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 May 2010 23:23:31 -0700 Subject: [Live-devel] Problem with rtcp In-Reply-To: <245C9F372D5A4C37AE987B73EB4A90F0@pcandrea> References: <245C9F372D5A4C37AE987B73EB4A90F0@pcandrea> Message-ID: >2) Any idea about why the presence of the rtcp messages modify >the vlc behavior in such a way that it can't play the video and >audio streams? Yes - it seems that you're not setting the presentation times correctly at the server ends for one or both of the audio and video streams. If you set correct, synchronized presentation times (aligned with 'wall clock time) at the server end, and use RTCP, then you will get proper time synchronization at the client end. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mohitagandotra at gmail.com Sun May 9 01:19:18 2010 From: mohitagandotra at gmail.com (mohita gandotra) Date: Sun, 9 May 2010 13:49:18 +0530 Subject: [Live-devel] RTP Timestamp to UTC time Message-ID: Hi All We are developing a client application using Live555. Our application have some specific requirement of converting the rtp timestamp of each video frame to utc time. So I have following query regarding this: 1.The MediaSink class of Live555 gets the presentation time as a parameter in aftergettingframe function.This presentation time can be converted to RTP timestamp using convertToRTPTimestamp function in RTPSink class.I just want to know how this rtp timestamp can be converted to UTC time. -- Mohita Gandotra -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun May 9 22:04:16 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 May 2010 22:04:16 -0700 Subject: [Live-devel] RTP Timestamp to UTC time In-Reply-To: References: Message-ID: >We are developing a client application using Live555. Do "we" not have a domain name? (If you use a "@gmail.com" email address, then you are assumed to be a casual hobbiest (whose posts are moderated and given a very low-priority), not a "we".) > Our application have some specific requirement of converting the >rtp timestamp of each video frame to utc time. So I have following >query regarding this: > >1.The MediaSink class of Live555 gets the presentation time as a >parameter in aftergettingframe function.This presentation time can >be converted to RTP timestamp using convertToRTPTimestamp function >in RTPSink class.I just want to know how this rtp timestamp can be >converted to UTC time. You don't need to know or care about RTP timestamps. Our software automatically converts from presentation time to RTP timestamp (at the server end), and then back from RTP timestamp to presentation time (at the client end). This is assuming, of course, that you use RTCP (which is a required part of the RTP/RTCP standard). So, just make sure that you give your streams proper presentation times at the server end - and you will get them automatically at the client end. These presentation times must be aligned with 'wall clock' time - i.e., the time that you would get by calling "gettimeofday()". (If "gettimeofday()" does not return UTC time, then you will need to apply the appropriate conversion at the client end. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From paul.kreker at fkie.fraunhofer.de Tue May 11 06:37:46 2010 From: paul.kreker at fkie.fraunhofer.de (Kreker, Paul) Date: Tue, 11 May 2010 15:37:46 +0200 Subject: [Live-devel] Tutorial for GUI (Qt4) Message-ID: <1FF0CFC89178B64DBD5CF6696750AC43388AF1@mailserv1.lorien.fkie.fgan.de> Hallo, I try to develop it myself, but it would be helpful if somebody could post a tutorial (Of course only if there is one.) or can describe he made it. With kind regards, Paul Kreker ------------------------------------------------------------------------ ------------------------------ Trainee to IT Specialist for Application Development Fraunhofer-Institution for Communikation, Informations Processing and Ergonomics (FKIE) Department Sensordata and Information Fusion (SDF) Neuenahrer Str. 20 53343 Wachtberg Germany Phone: +49 228 9435 456 Email: paul.kreker at fkie.fraunhofer.de Web: www.fkie.fraunhofer.de ------------------------------------------------------------------------ ------------------------------ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of this e-mail, its attachments and/or the information contained therein is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Tue May 11 16:42:34 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Tue, 11 May 2010 16:42:34 -0700 Subject: [Live-devel] Crash in RTSPServer.cpp In-Reply-To: References: Message-ID: On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring wrote: > On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson wrote: > >> >> It would be nice to find a simple, repeatable sequence of client >> operations that cause the crash. E.g., does crash ever happen if there are >> two complete "DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN" sequences in order >> (i.e., not overlapping), or does it occur only when two such sequences >> overlap? Once you've found a repeatable situation that causes the crash, >> then you could also test with RTP-over-UDP, and with "reuseFirstSource" set >> to False. > > > Okay, I did more testing. Definitely the issue is overlapping DESCRIBE, > SETUP, SETUP, PLAY, TEARDOWN sequences. And for me, the problem was > exacerbated by the fact that my client would connect to the server _twice_ > (once to fetch media types, then a TEARDOWN, and again to start pulling > media). I changed it so my code connects a single time and I can no longer > reproduce the crash. > > So I think there is a bug in there somewhere, and it definitely involves > overlapped sequences like that. I did try to isolate it with mediaServer > and openRTSP, but...haven't had a lot of luck. I'll let you know if I find > out anything else. > We're still having issues with this, so I had to do more testing. Instead of hitting with our client application, I used "openRTSP -t -d 1 " to hit our RTSP server. The RTSP server is configured to reuse sources. This time, I did managed to reproduce the crash: > RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(unsigned char requestByte='T') Line 322 + 0xf bytes C++ RTSPServer::RTSPClientSession::handleAlternativeRequestByte(void * instance=0x06010868, unsigned char requestByte='T') Line 317 C++ SocketDescriptor::tcpReadHandler(SocketDescriptor * socketDescriptor=0x05fdc2c0, int mask=2) Line 357 + 0x14 bytes C++ BasicTaskScheduler::SingleStep(unsigned int maxDelayTime=0) Line 115 + 0x11 bytes C++ BasicTaskScheduler0::doEventLoop(char * watchVariable=0x01f85698) Line 77 C++ void RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t requestByte) { // Add this character to our buffer; then try to handle the data that we have buffered so far: if (fRequestBufferBytesLeft == 0) return; fRequestBuffer[fRequestBytesAlreadySeen] = requestByte; // FAILED HERE handleRequestBytes(1); } fRequestBytesAlreadySeen is 3452816845, causing an access violation since fRequestBuffer is only 10 KB. I looked at the state of "this": - this 0x06010868 {fOurServer={...} fOurSessionId=3452816845 fOurServerMediaSession=0xcdcdcdcd ...} RTSPServer::RTSPClientSession * const + __vfptr 0xcdcdcdcd * + fOurServer {fServerSocket=??? fServerPort={...} fAuthDB=??? ...} RTSPServer & fOurSessionId 3452816845 unsigned int + fOurServerMediaSession 0xcdcdcdcd {fIsSSM=??? fSubsessionsHead=??? fSubsessionsTail=??? ...} ServerMediaSession * fClientSocket -842150451 int + fClientAddr {sin_family=-12851 sin_port=52685 sin_addr={...} ...} sockaddr_in fLivenessCheckTask 0xcdcdcdcd void * + fRequestBuffer 0x06010890 "?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????" unsigned char [10000] fRequestBytesAlreadySeen 3452816845 unsigned int fRequestBufferBytesLeft 3452816845 unsigned int + fLastCRLF 0xcdcdcdcd unsigned char * + fResponseBuffer 0x06012fac "?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????" unsigned char [10000] fIsMulticast 0 unsigned int fSessionIsActive 0 unsigned int fStreamAfterSETUP 4261281277 unsigned int + fCurrentAuthenticator {fRealm=0xabababab fNonce=0x00000000 fUsername=0x00000000 ...} Authenticator fTCPStreamIdCount 120 'x' unsigned char fNumStreamStates 100699448 unsigned int + fStreamStates 0x00000000 {subsession=??? streamToken=??? } RTSPServer::RTSPClientSession::streamState * This object is in a very weird state. the 0xcdcdcdcd values correspond with freshly allocated memory from the CRT (see http://www.nobugs.org/developer/win32/debug_crt_heap.html), so it appears to be an object that was just allocated--but this makes little sense given the implementation of RTSPClientSession. I'm not sure if this extra information helps or not. I'm going to work on running it under devpartner to see if anything else falls out of the woodwork. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.alen at uclouvain.be Wed May 12 06:12:37 2010 From: ivan.alen at uclouvain.be (Ivan Alen Fernandez) Date: Wed, 12 May 2010 15:12:37 +0200 Subject: [Live-devel] Interactive straming of H264 files to VLC Message-ID: <79bcb2bcb9b184c08208886f00d5d8c4.squirrel@mmp.sipr-dc.ucl.ac.be> Hello, i am working on interactive streaming and i am using the live 555 media library to deliver my packages encoded in x264 to a vlc client. In order to improve the performance of the interactive streaming i have to develop an adaptative algorithm based on the vlc player buffer size and i should be able to modify this buffer(make it shorter) size to achieve a faster response of the switching of the streams in the client size. Do you know if it is possible to define dynamically or statically from the server side, the size of the buffer of the client of the streaming? Is there any option through the rtp, rtcp or rtsp protocol? Thanks a lot for all your code and help Best Iv?n From jnoring at logitech.com Wed May 12 13:56:44 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Wed, 12 May 2010 13:56:44 -0700 Subject: [Live-devel] Crash in RTSPServer.cpp In-Reply-To: References: Message-ID: On Tue, May 11, 2010 at 4:42 PM, Jeremy Noring wrote: > On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring wrote: > >> On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson wrote: >> >>> >>> It would be nice to find a simple, repeatable sequence of client >>> operations that cause the crash. E.g., does crash ever happen if there are >>> two complete "DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN" sequences in order >>> (i.e., not overlapping), or does it occur only when two such sequences >>> overlap? Once you've found a repeatable situation that causes the crash, >>> then you could also test with RTP-over-UDP, and with "reuseFirstSource" set >>> to False. >> >> Okay, I've now managed to reproduce this with openRTSP and testOnDemandRTSPServer (which is what our RTSP server is modeled after). To reproduce it, you need to: 1. Have your RTSP server deliver a media session with multiple subsessions. (i.e. simply trying to reproduce with mp3AudioTest will not work; you have to have a session with audio _and_ video, for example). I simply combined the .wav and .mp3 sessions into one: { char const* streamName = "mp3AudioTest"; char const* inputFileName = "test.mp3"; ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); Boolean useADUs = False; Interleaving* interleaving = NULL; #ifdef STREAM_USING_ADUS useADUs = True; #ifdef INTERLEAVE_ADUS unsigned char interleaveCycle[] = {0,2,1,3}; // or choose your own... unsigned const interleaveCycleSize = (sizeof interleaveCycle)/(sizeof (unsigned char)); interleaving = new Interleaving(interleaveCycleSize, interleaveCycle); #endif #endif sms->addSubsession(MP3AudioFileServerMediaSubsession ::createNew(*env, inputFileName, reuseFirstSource, useADUs, interleaving)); // To convert 16-bit PCM data to 8-bit u-law, prior to streaming, // change the following to True: inputFileName = "test.wav"; Boolean convertToULaw = False; sms->addSubsession(WAVAudioFileServerMediaSubsession ::createNew(*env, inputFileName, reuseFirstSource, convertToULaw)); rtspServer->addServerMediaSession(sms); announceStream(rtspServer, sms, streamName, inputFileName); } 2. Set reuseFirstSource to True 3. Run multiple openRTSP instances to repeatedly hit the RTSP server streaming with TCP. I use "openRTSP -t -d 1 url", and have a small program that calls that repeatedly. Next, I'm going to isolate if this is regression in the codebase, or if it's something that was a problem before the recent RTP-over-TCP changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed May 12 17:56:34 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 May 2010 17:56:34 -0700 Subject: [Live-devel] Interactive straming of H264 files to VLC In-Reply-To: <79bcb2bcb9b184c08208886f00d5d8c4.squirrel@mmp.sipr-dc.ucl.ac.be> References: <79bcb2bcb9b184c08208886f00d5d8c4.squirrel@mmp.sipr-dc.ucl.ac.be> Message-ID: >Hello, i am working on interactive streaming and i am using the live 555 >media library to deliver my packages encoded in x264 to a vlc client. > >In order to improve the performance of the interactive streaming i have to >develop an adaptative algorithm based on the vlc player buffer size and i >should be able to modify this buffer(make it shorter) size to achieve a >faster response of the switching of the streams in the client size. > >Do you know if it is possible to define dynamically or statically from the >server side, the size of the buffer of the client of the streaming? > >Is there any option through the rtp, rtcp or rtsp protocol? Yes, you can use the RTCP-provided "jitter" statistic for this purpose. Note the "RTPReceptionStats" class. To access this class, see, for example, how "openRTSP" implements the "-Q" option. To be honest, I'm not sure how you would use the "jitter" statistic to calculate an estimate of the client's buffer size, but there's probably information out there on the Internet about this... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From a.nemec at atlas.cz Thu May 13 01:14:47 2010 From: a.nemec at atlas.cz (=?UTF-8?Q?Alexandr=20N=C4=9Bmec?=) Date: Thu, 13 May 2010 10:14:47 +0200 Subject: [Live-devel] Jitter calculations Message-ID: <1273738487.814086.10606.nullmailer@mail1001.cent> Dear all, I have a question regarding interarrival jitter calculations for RTP packets. In RTPSource.cpp only packets with different RTP timestamps are used for jitter calculations, so if two or more packets have the same RTP time stamp, only the first one is used for interarrival jitter calculation. Ok, this makes somehow sense to me, because a video frame is usually split into several RTP packets all having the same timestamp and since jitter calculations are time based, only the first packet (the first one that arrives) might be interesting for jitter calculation because the rest would reduce the jitter accuracy. But my problem is that the RFC clearly states that for jitter calculations all packets should be used even with these (and similar) side effects. So, what is the standard compliant way of calculating the interarrival jitter for RTP packets? Thanks for your help Alex From finlayson at live555.com Thu May 13 18:05:47 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 May 2010 18:05:47 -0700 Subject: [Live-devel] Jitter calculations In-Reply-To: <1273738487.814086.10606.nullmailer@mail1001.cent> References: <1273738487.814086.10606.nullmailer@mail1001.cent> Message-ID: Yes, I guess the current implementation - by not calculating jitter from every incoming packet - isn't really following the RTP/RTCP spec. I'm not sure why I did things this way; it was probably years ago. I might go ahead and change this in a future release. In the meantime, feel free to change the "if" statement at line 291 of "RTPSource.cpp" to "if (1) ..." -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From a.nemec at atlas.cz Mon May 17 07:52:41 2010 From: a.nemec at atlas.cz (=?UTF-8?Q?Alexandr=20N=C4=9Bmec?=) Date: Mon, 17 May 2010 16:52:41 +0200 Subject: [Live-devel] RR packets once again Message-ID: <1274107961.896129.18124.nullmailer@mail1009.cent> Deal all, I have a question regarding RTCP RR packets. My RTSP server uses the RR packets as liveness indicator of my client and the live555 code correctly sends RR packets to the server if using live555 code as the client. This prevents my server from timing out the client which it does when it does not see any RR packets. When I use the RTP over RTSP interleaved mode, it seems to me that the server does not use/need the RTCP packets, but live555 client code sends the RR packets even over TCP. I made a quick check in the RFC (the chapter about the interleaved mode) and it says that?"RTCP messages are also interleaved by the server over the TCP connection". But nothing about the client which confused me. 1. Is it necessary or standard compliant to send RTCP RR packets as a client in RTP over RTSP interleaved mode? My RTSP server seems to ignore them in this mode. 2. The same question regarding RTSP over HTTP. Again, the server ignores RTCP of the client in this case and I also found a recommendation somewhere (some quicktime stuff), that the POST connection used for sending RTSP requests to the server can be closed after the PLAY request which leads to the conclusion that no RTCP packets are sent by the client in this mode. I hope anybody knows the answers here (at least Ross will know them for sure :). Thanks very much in advance. Best regads Alex From finlayson at live555.com Mon May 17 11:11:12 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 May 2010 11:11:12 -0700 Subject: [Live-devel] RR packets once again In-Reply-To: <1274107961.896129.18124.nullmailer@mail1009.cent> References: <1274107961.896129.18124.nullmailer@mail1009.cent> Message-ID: >1. Is it necessary or standard compliant to send RTCP RR packets as >a client in RTP over RTSP interleaved mode? Yes, because RTCP "RR" packets contain useful information; they're used for more than just liveness indications. > My RTSP server seems to ignore them in this mode. Are you using the most up-to-date version of the code (for your RTSP server)?? This bug should no longer exist. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From den.dgtex at gmail.com Mon May 17 03:28:15 2010 From: den.dgtex at gmail.com (Denis Z) Date: Mon, 17 May 2010 14:28:15 +0400 Subject: [Live-devel] RTSPClient::describeURL with bad IP Message-ID: Hi! When I call RTSPClient::describeURL with IP-address which is not exist in the network (for example - 10.10.10.10), this call blocks for about 20 seconds before it return an error. Sometimes I need to terminate this waiting and cancel "describeURL" operation immediately, but I didn't found how to do that. How can I cancel "describeURL" operation while it in progress? Thanks! Denis. From a.nemec at atlas.cz Mon May 17 23:12:40 2010 From: a.nemec at atlas.cz (=?UTF-8?Q?Alexandr=20N=C4=9Bmec?=) Date: Tue, 18 May 2010 08:12:40 +0200 Subject: [Live-devel] RR packets once again In-Reply-To: References: <1274107961.896129.18124.nullmailer@mail1009.cent> Message-ID: <1274163160.530855.13800.nullmailer@mail1003.cent> Dear Ross, thanks very much for the information. Alex ______________________________________________________________ > Od: "Ross Finlayson" > Komu: LIVE555 Streaming Media - development & use > Datum: 17.05.2010 20:13 > P?edm?t: Re: [Live-devel] RR packets once again > >1. Is it necessary or standard compliant to send RTCP RR packets as >a client in RTP over RTSP interleaved mode? Yes, because RTCP "RR" packets contain useful information; they're used for more than just liveness indications. > ?My RTSP server seems to ignore them in this mode. Are you using the most up-to-date version of the code (for your RTSP server)?? ?This bug should no longer exist. -- 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 timchen.xiaoming at gmail.com Wed May 19 00:09:41 2010 From: timchen.xiaoming at gmail.com (xiaoming chen) Date: Wed, 19 May 2010 15:09:41 +0800 Subject: [Live-devel] linking error Message-ID: Hi,guys, I now install a library named omnimeeting, which use live555 ,ffmpeg and opencv as former library. There is nothing wrong when install, but I meet error when linking the library. Here is the error information: /usr/local/lib/libomnistream.so: undefined reference to `av_set_parameters(AVFormatContext*, AVFormatParameters*)' /usr/local/lib/libomnistream.so: undefined reference to `av_open_input_file(AVFormatContext**, char const*, AVInputFormat*, int, AVFormatParameters*)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::wasLoopedBackFromUs(UsageEnvironment&, sockaddr_in&)' /usr/local/lib/libomnistream.so: undefined reference to `av_find_stream_info(AVFormatContext*)' /usr/local/lib/libomnistream.so: undefined reference to `HashTable::create(int)' /usr/local/lib/libomnistream.so: undefined reference to `HashTable::RemoveNext()' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::~Groupsock()' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_find_encoder(CodecID)' /usr/local/lib/libomnistream.so: undefined reference to `sws_getContext(int, int, PixelFormat, int, int, PixelFormat, int, SwsFilter*, SwsFilter*, double*)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_find_decoder(CodecID)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_alloc_context()' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::removeAllDestinations()' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_close(AVCodecContext*)' /usr/local/lib/libomnistream.so: undefined reference to `av_read_frame(AVFormatContext*, AVPacket*)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_alloc_frame()' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::Groupsock(UsageEnvironment&, in_addr const&, Port, unsigned char)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_encode_audio(AVCodecContext*, unsigned char*, int, short const*)' /usr/local/lib/libomnistream.so: undefined reference to `guess_format(char const*, char const*, char const*)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_open(AVCodecContext*, AVCodec*)' /usr/local/lib/libomnistream.so: undefined reference to `HashTable::Iterator::create(HashTable&)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_init()' /usr/local/lib/libomnistream.so: undefined reference to `strDup(char const*)' /usr/local/lib/libomnistream.so: undefined reference to `av_close_input_file(AVFormatContext*)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_decode_video(AVCodecContext*, AVFrame*, int*, unsigned char const*, int)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_register_all()' /usr/local/lib/libomnistream.so: undefined reference to `sws_freeContext(SwsContext*)' /usr/local/lib/libomnistream.so: undefined reference to `av_free(void*)' /usr/local/lib/libomnistream.so: undefined reference to `sws_scale(SwsContext*, unsigned char**, int*, int, int, unsigned char**, int*)' /usr/local/lib/libomnistream.so: undefined reference to `av_alloc_format_context()' /usr/local/lib/libomnistream.so: undefined reference to `avpicture_fill(AVPicture*, unsigned char*, int, int, int)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::removeDestination(in_addr const&, Port const&)' /usr/local/lib/libomnistream.so: undefined reference to `av_register_all()' /usr/local/lib/libomnistream.so: undefined reference to `avformat_alloc_context()' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::addDestination(in_addr const&, Port const&)' /usr/local/lib/libomnistream.so: undefined reference to `av_new_stream(AVFormatContext*, int)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::multicastSendOnly()' /usr/local/lib/libomnistream.so: undefined reference to `avpicture_get_size(int, int, int)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::changeDestinationParameters(in_addr const&, Port, int)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::Groupsock(UsageEnvironment&, in_addr const&, in_addr const&, Port)' /usr/local/lib/libomnistream.so: undefined reference to `strDupSize(char const*)' /usr/local/lib/libomnistream.so: undefined reference to `avcodec_encode_video(AVCodecContext*, unsigned char*, int, AVFrame const*)' /usr/local/lib/libomnistream.so: undefined reference to `av_find_input_format(char const*)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::output(UsageEnvironment&, unsigned char, unsigned char*, unsigned int, DirectedNetInterface*)' I search for a solution for linking error about ffmpeg library: extern "C" { #define __STDC_CONSTANT_MACROS #include #include } And now the function in two libraries is ok, but still errors about others: /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::wasLoopedBackFromUs(UsageEnvironment&, sockaddr_in&)' /usr/local/lib/libomnistream.so: undefined reference to `HashTable::create(int)' /usr/local/lib/libomnistream.so: undefined reference to `HashTable::RemoveNext()' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::~Groupsock()' /usr/local/lib/libomnistream.so: undefined reference to `sws_getContext(int, int, PixelFormat, int, int, PixelFormat, int, SwsFilter*, SwsFilter*, double*)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::removeAllDestinations()' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::Groupsock(UsageEnvironment&, in_addr const&, Port, unsigned char)' /usr/local/lib/libomnistream.so: undefined reference to `HashTable::Iterator::create(HashTable&)' /usr/local/lib/libomnistream.so: undefined reference to `strDup(char const*)' /usr/local/lib/libomnistream.so: undefined reference to `sws_freeContext(SwsContext*)' /usr/local/lib/libomnistream.so: undefined reference to `sws_scale(SwsContext*, unsigned char**, int*, int, int, unsigned char**, int*)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::removeDestination(in_addr const&, Port const&)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::addDestination(in_addr const&, Port const&)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::multicastSendOnly()' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::changeDestinationParameters(in_addr const&, Port, int)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::Groupsock(UsageEnvironment&, in_addr const&, in_addr const&, Port)' /usr/local/lib/libomnistream.so: undefined reference to `strDupSize(char const*)' /usr/local/lib/libomnistream.so: undefined reference to `Groupsock::output(UsageEnvironment&, unsigned char, unsigned char*, unsigned int, DirectedNetInterface*)' These errors are mostly about the live555 libraries. And I'm confused again. Could someone do me a favor? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesuas at gmail.com Wed May 19 05:35:22 2010 From: jesuas at gmail.com (Anuroop Jesu) Date: Wed, 19 May 2010 18:05:22 +0530 Subject: [Live-devel] linking error In-Reply-To: References: Message-ID: check whether you are linking following "*-lgroupsock*" With Warm Regards Jesu Anuroop Suresh "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." "Anyone who has never made a mistake has never tried anything new." On Wed, May 19, 2010 at 12:39 PM, xiaoming chen wrote: > Hi,guys, I now install a library named omnimeeting, which use live555 > ,ffmpeg and opencv as former library. > There is nothing wrong when install, but I meet error when linking the > library. Here is the error information: > > /usr/local/lib/libomnistream.so: undefined reference to > `av_set_parameters(AVFormatContext*, AVFormatParameters*)' > /usr/local/lib/libomnistream.so: undefined reference to > `av_open_input_file(AVFormatContext**, char const*, AVInputFormat*, int, > AVFormatParameters*)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::wasLoopedBackFromUs(UsageEnvironment&, sockaddr_in&)' > /usr/local/lib/libomnistream.so: undefined reference to > `av_find_stream_info(AVFormatContext*)' > /usr/local/lib/libomnistream.so: undefined reference to > `HashTable::create(int)' > /usr/local/lib/libomnistream.so: undefined reference to > `HashTable::RemoveNext()' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::~Groupsock()' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_find_encoder(CodecID)' > /usr/local/lib/libomnistream.so: undefined reference to > `sws_getContext(int, int, PixelFormat, int, int, PixelFormat, int, > SwsFilter*, SwsFilter*, double*)' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_find_decoder(CodecID)' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_alloc_context()' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::removeAllDestinations()' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_close(AVCodecContext*)' > /usr/local/lib/libomnistream.so: undefined reference to > `av_read_frame(AVFormatContext*, AVPacket*)' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_alloc_frame()' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::Groupsock(UsageEnvironment&, in_addr const&, Port, unsigned > char)' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_encode_audio(AVCodecContext*, unsigned char*, int, short const*)' > /usr/local/lib/libomnistream.so: undefined reference to `guess_format(char > const*, char const*, char const*)' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_open(AVCodecContext*, AVCodec*)' > /usr/local/lib/libomnistream.so: undefined reference to > `HashTable::Iterator::create(HashTable&)' > /usr/local/lib/libomnistream.so: undefined reference to `avcodec_init()' > /usr/local/lib/libomnistream.so: undefined reference to `strDup(char > const*)' > /usr/local/lib/libomnistream.so: undefined reference to > `av_close_input_file(AVFormatContext*)' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_decode_video(AVCodecContext*, AVFrame*, int*, unsigned char const*, > int)' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_register_all()' > /usr/local/lib/libomnistream.so: undefined reference to > `sws_freeContext(SwsContext*)' > /usr/local/lib/libomnistream.so: undefined reference to `av_free(void*)' > /usr/local/lib/libomnistream.so: undefined reference to > `sws_scale(SwsContext*, unsigned char**, int*, int, int, unsigned char**, > int*)' > /usr/local/lib/libomnistream.so: undefined reference to > `av_alloc_format_context()' > /usr/local/lib/libomnistream.so: undefined reference to > `avpicture_fill(AVPicture*, unsigned char*, int, int, int)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::removeDestination(in_addr const&, Port const&)' > /usr/local/lib/libomnistream.so: undefined reference to `av_register_all()' > /usr/local/lib/libomnistream.so: undefined reference to > `avformat_alloc_context()' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::addDestination(in_addr const&, Port const&)' > /usr/local/lib/libomnistream.so: undefined reference to > `av_new_stream(AVFormatContext*, int)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::multicastSendOnly()' > /usr/local/lib/libomnistream.so: undefined reference to > `avpicture_get_size(int, int, int)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::changeDestinationParameters(in_addr const&, Port, int)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::Groupsock(UsageEnvironment&, in_addr const&, in_addr const&, > Port)' > /usr/local/lib/libomnistream.so: undefined reference to `strDupSize(char > const*)' > /usr/local/lib/libomnistream.so: undefined reference to > `avcodec_encode_video(AVCodecContext*, unsigned char*, int, AVFrame const*)' > /usr/local/lib/libomnistream.so: undefined reference to > `av_find_input_format(char const*)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::output(UsageEnvironment&, unsigned char, unsigned char*, > unsigned int, DirectedNetInterface*)' > > I search for a solution for linking error about ffmpeg library: > extern "C" { > #define __STDC_CONSTANT_MACROS > #include > #include > } > > And now the function in two libraries is ok, but still errors about others: > > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::wasLoopedBackFromUs(UsageEnvironment&, sockaddr_in&)' > /usr/local/lib/libomnistream.so: undefined reference to > `HashTable::create(int)' > /usr/local/lib/libomnistream.so: undefined reference to > `HashTable::RemoveNext()' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::~Groupsock()' > /usr/local/lib/libomnistream.so: undefined reference to > `sws_getContext(int, int, PixelFormat, int, int, PixelFormat, int, > SwsFilter*, SwsFilter*, double*)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::removeAllDestinations()' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::Groupsock(UsageEnvironment&, in_addr const&, Port, unsigned > char)' > /usr/local/lib/libomnistream.so: undefined reference to > `HashTable::Iterator::create(HashTable&)' > /usr/local/lib/libomnistream.so: undefined reference to `strDup(char > const*)' > /usr/local/lib/libomnistream.so: undefined reference to > `sws_freeContext(SwsContext*)' > /usr/local/lib/libomnistream.so: undefined reference to > `sws_scale(SwsContext*, unsigned char**, int*, int, int, unsigned char**, > int*)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::removeDestination(in_addr const&, Port const&)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::addDestination(in_addr const&, Port const&)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::multicastSendOnly()' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::changeDestinationParameters(in_addr const&, Port, int)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::Groupsock(UsageEnvironment&, in_addr const&, in_addr const&, > Port)' > /usr/local/lib/libomnistream.so: undefined reference to `strDupSize(char > const*)' > /usr/local/lib/libomnistream.so: undefined reference to > `Groupsock::output(UsageEnvironment&, unsigned char, unsigned char*, > unsigned int, DirectedNetInterface*)' > > These errors are mostly about the live555 libraries. And I'm confused > again. > Could someone do me a favor? > > _______________________________________________ > 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 andy at j2kvideo.com Thu May 20 03:17:52 2010 From: andy at j2kvideo.com (Andy Bell) Date: Thu, 20 May 2010 12:17:52 +0200 Subject: [Live-devel] Getting the JPEG payload from a JPEG file Message-ID: Hi, I have used the 'Elphel' code to build a simple RTSP server which streams a fixed JPEG frame. I want to be able to configure the RTSP server to use a specific JPEG file on disk. The problem I have is that different JPEG files have different header sizes and I want to work out how I can work out where the header ends and where the payload begins. Looking at the header I can locate the start of the scan using the marker 0xFFDA, but even when I send this back to the client I don't get a valid image. As I am using a JPEG file I have no idea of the Q factor so I have set this to 100 for the time being. Is there any code out there which can help me break up a JPEG file from disk and stream it back to the client? If not, where am I going wrong? Thanks Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtebcherani at awox.com Thu May 20 09:52:06 2010 From: jtebcherani at awox.com (Jacques Tebcherani) Date: Thu, 20 May 2010 18:52:06 +0200 Subject: [Live-devel] Modify testWAVAudioStreamer to take input from a Buffer Message-ID: <46423D9081D5254CAFCEFF0CBC2CC9BAC76E50@jakarta.awox.com> Hi, The "testWAVAudioStreamer.cpp" test program reads from a WAV file. How can I modify it so that it takes input from a Buffer instead? Regards, Jacques Tebcherani -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 20 18:54:12 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 May 2010 18:54:12 -0700 Subject: [Live-devel] Modify testWAVAudioStreamer to take input from a Buffer In-Reply-To: <46423D9081D5254CAFCEFF0CBC2CC9BAC76E50@jakarta.awox.com> References: <46423D9081D5254CAFCEFF0CBC2CC9BAC76E50@jakarta.awox.com> Message-ID: >The "testWAVAudioStreamer.cpp" test program reads from a WAV file. >How can I modify it so that it takes input from a Buffer instead? You will need to write your own subclass of "FramedSource" (that encapsulates your buffer), and, in particular, implement the "doGetNextFrame()" virtual function. Because you're streaming PCM data, you should use "WAVAudioFileSource::doGetNextFrame()" as a model for how to implement this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Thu May 20 22:17:53 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Thu, 20 May 2010 22:17:53 -0700 Subject: [Live-devel] Getting the JPEG payload from a JPEG file In-Reply-To: References: Message-ID: On Thu, May 20, 2010 at 3:17 AM, Andy Bell wrote: > Hi, > > I have used the 'Elphel' code to build a simple RTSP server which streams a > fixed JPEG frame. I want to be able to configure the RTSP server to use a > specific JPEG file on disk. The problem I have is that different JPEG files > have different header sizes and I want to work out how I can work out where > the header ends and where the payload begins. Looking at the header I can > locate the start of the scan using the marker 0xFFDA, but even when I send > this back to the client I don't get a valid image. As I am using a JPEG > file I have no idea of the Q factor so I have set this to 100 for the time > being. Is there any code out there which can help me break up a JPEG file > from disk and stream it back to the client? If not, where am I going wrong? > > You could probably use libjpeg (http://www.ijg.org/) to get at the raw image data. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at j2kvideo.com Fri May 21 10:16:49 2010 From: andy at j2kvideo.com (Andy Bell) Date: Fri, 21 May 2010 19:16:49 +0200 Subject: [Live-devel] Buffer size on client Message-ID: Hi, I am looking at the Elphel example and I would like to stream MJPEG where the frame size would be in the region of 200KB, I have tried increasing the OutPacketBuffer::maxSize but I am still not able to view the stream in VLC. If I use openRTSP I get the following message: MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (100000). 583 bytes of trailing data will be dropped! Do I just need to increase the buffer size on the client? If so how do I do increase the buffer on the client side? How do I increase this buffer using the live555 API? Thanks in advance Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri May 21 13:45:09 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 May 2010 13:45:09 -0700 Subject: [Live-devel] Buffer size on client In-Reply-To: References: Message-ID: >I am looking at the Elphel example and I would like to stream MJPEG >where the frame size would be in the region of 200KB, I have tried >increasing the OutPacketBuffer::maxSize but I am still not able to >view the stream in VLC. If I use openRTSP I get the following >message: > >MultiFramedRTPSource::doGetNextFrame1(): The total received frame >size exceeds the client's buffer size (100000). 583 bytes of >trailing data will be dropped! > >Do I just need to increase the buffer size on the client? If so how >do I do increase the buffer on the client side? Just use the "-b " option to "openRTSP"; see I hope you realize, though, that JPEG is a very poor codec for video streaming, because each frame is so large (and so takes up many network packets). If *any* of these network packets gets lost, then the whole frame must be discarded. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From anirban.duttachoudhury at gmail.com Thu May 20 01:46:16 2010 From: anirban.duttachoudhury at gmail.com (Anirban Dutta Choudhury) Date: Thu, 20 May 2010 10:46:16 +0200 Subject: [Live-devel] delay in h.264 streaming using mplayer Message-ID: Hi, I am experiencing an accumulating delay while playing h.264 stream using mplayer(1.0 rc2-4.3.2). The delay is accumulating very slowly. Initially, there is no noticeable delay at all for first 10-15 min. And then gradually, the delay becomes visible. After a overnight run, the video looks frozen. And then every now and then, there is some jerky video playback (like one will see while fast-forwarding a video), and then the video freezes. I used following command line options and followed the mplayer manual to my very best, but in vain. -slave -flip -nosound -nomousinput -loop 0 -lavdopts skiploopfilter=nonref -hardframedrop I tried the same in windows. There I have a constant delay of 1 sec. But nothing is getting frozen. So, my guess is that it may be some buffer in live555 is getting filled up. What else can I try? Regards, Anirban -- ------------------------------------------- Anirban Dutta Choudhury ------------------------------------------- From anirban.duttachoudhury at gmail.com Thu May 20 02:14:42 2010 From: anirban.duttachoudhury at gmail.com (Anirban Dutta Choudhury) Date: Thu, 20 May 2010 11:14:42 +0200 Subject: [Live-devel] Fwd: delay in h.264 streaming using mplayer In-Reply-To: References: Message-ID: Tried suing the latest mplayer and live555, bbut with same result. Here is the output data. [anirban.dutta at localhost app_test]$ mplayer rtsp://root:pass at 172.16.1.1/axis-media/media.amp -rtsp-stream-over-tcp -hardframedrop MPlayer SVN-r31151-4.1.2 (C) 2000-2010 MPlayer Team Playing rtsp://root:pass at 172.16.1.1/axis-media/media.amp. Resolving 172.16.1.1 for AF_INET6... Couldn't resolve name for AF_INET6: 172.16.1.1 Connecting to server 172.16.1.1[172.16.1.1]: 554... librtsp: server responds: 'RTSP/1.0 401 Unauthorized' rtsp_session: unsupported RTSP server. Server type is 'unknown'. STREAM_LIVE555, URL: rtsp://root:pass at 172.16.1.1/axis-media/media.amp Stream not seekable! file format detected. Unable to determine our source address: This computer has an invalid IP address: 0x0 Unable to determine our source address: This computer has an invalid IP address: 0x0 Initiated "video/H264" RTP subsession on port 32784 VIDEO: [H264] 0x0 0bpp 15.000 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== Audio: no sound Starting playback... Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [xv] 320x240 => 320x240 Planar YV12 V:63522.7 641930/641930 3% 0% 0.0% 0 0 Regards, Anirban From linun77 at gmail.com Thu May 20 08:09:57 2010 From: linun77 at gmail.com (Nuno Cardoso) Date: Thu, 20 May 2010 16:09:57 +0100 Subject: [Live-devel] save h.264 stream to file Message-ID: Hi list, I'm using the command "./openRTSP -4 -d 10 rtsp://192.168.1.163 > output.mp4" to capture an h.264 camera IP stream and save it to a file. Is that the right command to do this? When I try to play the output.mp4 file with VLC Player, vlc doesn't show anything.... What is the problem? Thanks, linun77 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri May 21 14:58:59 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 May 2010 14:58:59 -0700 Subject: [Live-devel] delay in h.264 streaming using mplayer In-Reply-To: References: Message-ID: >I am experiencing an accumulating delay while playing h.264 stream >using mplayer(1.0 rc2-4.3.2). [...] >What else can I try? VLC. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andy at j2kvideo.com Sat May 22 00:35:46 2010 From: andy at j2kvideo.com (Andy Bell) Date: Sat, 22 May 2010 09:35:46 +0200 Subject: [Live-devel] Buffer size on client In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 10:45 PM, Ross Finlayson wrote: > I am looking at the Elphel example and I would like to stream MJPEG where > the frame size would be in the region of 200KB, I have tried increasing > the OutPacketBuffer::maxSize but I am still not able to view the stream in > VLC. If I use openRTSP I get the following message: > > > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (100000). 583 bytes of trailing data will > be dropped! > > > Do I just need to increase the buffer size on the client? If so how do I do > increase the buffer on the client side? > > > Just use the "-b " option to "openRTSP"; see < > http://www.live555.com/openRTSP/#other-options> > > I hope you realize, though, that JPEG is a very poor codec for video > streaming, because each frame is so large (and so takes up many network > packets). If *any* of these network packets gets lost, then the whole frame > must be discarded. > > > Thanks. I do realise that its a poor codec but I want to generate a video stream of around 15Mbps and JPEG seemed the easiest. Is there no way of sending the frame in more packets so that there is no packet loss? Thanks Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat May 22 00:49:36 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 22 May 2010 00:49:36 -0700 Subject: [Live-devel] Buffer size on client In-Reply-To: References: Message-ID: >I hope you realize, though, that JPEG is a very poor codec for video >streaming, because each frame is so large (and so takes up many >network packets). If *any* of these network packets gets lost, then >the whole frame must be discarded. > >Thanks. I do realise that its a poor codec but I want to generate a >video stream of around 15Mbps and JPEG seemed the easiest. Is there >no way of sending the frame in more packets so that there is no >packet loss? ??? If JPEG frames were packed into more packets, then you'd be *more* likely to see packet loss (thereby resulting in the loss of a JPEG frame). However, you should also reread http://www.live555.com/liveMedia/faq.html#packet-loss This might help you. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at j2kvideo.com Sat May 22 05:09:48 2010 From: andy at j2kvideo.com (Andy Bell) Date: Sat, 22 May 2010 14:09:48 +0200 Subject: [Live-devel] Buffer size on client In-Reply-To: References: Message-ID: On Sat, May 22, 2010 at 9:49 AM, Ross Finlayson wrote: > I hope you realize, though, that JPEG is a very poor codec for video > streaming, because each frame is so large (and so takes up many network > packets). If *any* of these network packets gets lost, then the whole frame > must be discarded. > > > Thanks. I do realise that its a poor codec but I want to generate a > video stream of around 15Mbps and JPEG seemed the easiest. Is there no way > of sending the frame in more packets so that there is no packet loss? > > > ??? If JPEG frames were packed into more packets, then you'd be *more* > likely to see packet loss (thereby resulting in the loss of a JPEG frame). > > However, you should also reread > http://www.live555.com/liveMedia/faq.html#packet-loss This might help > you. > > > OK. So could I stream over TCP rather than UDP? Thanks Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanlantao at gmail.com Fri May 21 15:43:49 2010 From: lanlantao at gmail.com (Tao Wu) Date: Fri, 21 May 2010 17:43:49 -0500 Subject: [Live-devel] livemedia lib throughput speed limitations Message-ID: Hi, I am trying to figure out the H264 throughput speed of livemedia library. As I know, the library uses durationInMicroseconds in H264FUAFragmenter::afterGettingFrame, which finally passes the value to MultiFramedRTPSink::sendPacketIfNecessary() to determine the when to send next frame. ( struct timeval timeNow; gettimeofday(&timeNow, NULL); int uSecondsToGo; if (fNextSendTime.tv_sec < timeNow.tv_sec || (fNextSendTime.tv_sec == timeNow.tv_sec && fNextSendTime.tv_usec < timeNow.tv_usec)) { uSecondsToGo = 0; // prevents integer underflow if too far behind } else { uSecondsToGo = (fNextSendTime.tv_sec - timeNow.tv_sec)*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec); } // Delay this amount of time: nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo, (TaskFunc*)sendNext, this); ). So I adjusted the value of durationInMicroseconds from 33 ms to 1 ms to observe how fast the library can stream a file. In the experiments, I chose a small 2MB file to eliminate the impacts of the hard drive (the library reads the file in memory before streaming). The average size of h264 frames is around 20KB. openRTSP is used as the client to receive the file. When the durationInMicroseconds goes to about 1 ms, a significant packet loss is observed (from the received file size by openRTSP). Now the question is what cause the packet loss. Is the UDP over network (network or Linux can not handle it) or the library itself drops the RTP packet because the CPU can not process that fast (from the above fNextSendTime, timeNow, I believe a lots of delayed task events will set uSecondsToGo=0)? If I want to stream a file very fast and reasonably reliable, what is best direction to go? Thanks for any comments. Tao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmigdal at gmail.com Fri May 21 16:11:07 2010 From: jmigdal at gmail.com (Joshua Migdal) Date: Fri, 21 May 2010 19:11:07 -0400 Subject: [Live-devel] save h.264 stream to file In-Reply-To: References: Message-ID: you need to specify the width and height of the output file. -w and -h options. You can also specify the fps if you want. If not, it will default to 15 fps. On Thu, May 20, 2010 at 11:09 AM, Nuno Cardoso wrote: > Hi list, > > I'm using the command "./openRTSP -4? -d 10 rtsp://192.168.1.163 > > output.mp4" to capture an h.264 camera IP stream and save it to a file. Is > that the right command to do this? > > When I try to play the output.mp4 file with VLC Player, vlc doesn't show > anything.... What is the problem? > > Thanks, > linun77 > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > From finlayson at live555.com Sun May 23 00:12:39 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 23 May 2010 00:12:39 -0700 Subject: [Live-devel] livemedia lib throughput speed limitations In-Reply-To: References: Message-ID: >When the durationInMicroseconds goes to about 1 ms, a significant >packet loss is observed (from the received file size by openRTSP). >Now the question is what cause the packet loss. Read the FAQ! -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jnoring at logitech.com Sun May 23 10:43:23 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Sun, 23 May 2010 10:43:23 -0700 Subject: [Live-devel] livemedia lib throughput speed limitations In-Reply-To: References: Message-ID: On Fri, May 21, 2010 at 3:43 PM, Tao Wu wrote: > If I want to stream a file very fast and reasonably reliable, what is best > direction to go? > Use RTP over TCP. Also, it sounds like you're not interested in "streaming" a file but "transferring" a file, in which case you could get away with using something much more simple than RTSP/RTP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvasilkov at gmail.com Sun May 23 08:32:21 2010 From: mvasilkov at gmail.com (Mark Vasilkov) Date: Sun, 23 May 2010 18:32:21 +0300 Subject: [Live-devel] Config for iPhone OS. Message-ID: Hello there. Since I could not google my way to config file suitable for cross-compiling for iPhone OS (on a Mac), I wrote my own and decided to share it with the community. --- ~ http://animuchan.net/ ~ -------------- next part -------------- A non-text attachment was scrubbed... Name: config.iphoneos Type: application/octet-stream Size: 840 bytes Desc: not available URL: From finlayson at live555.com Sun May 23 21:18:14 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 23 May 2010 21:18:14 -0700 Subject: [Live-devel] Config for iPhone OS. In-Reply-To: References: Message-ID: >Since I could not google my way to config file suitable for >cross-compiling for iPhone OS (on a Mac), I wrote my own and decided >to share it with the community. Thanks. This will be included with the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From grs.tanya at gmail.com Thu May 27 04:54:57 2010 From: grs.tanya at gmail.com (Groysberg Tanya) Date: Thu, 27 May 2010 13:54:57 +0200 Subject: [Live-devel] Teletext channel Message-ID: Hi, I couldn't find in live555 library is there a way to support teletext channel via the RTSP live media server? Thanks in advance, Tanya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 27 07:14:20 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 May 2010 07:14:20 -0700 Subject: [Live-devel] New version installed; updates "TaskScheduler" API Message-ID: (If you have not written your own subclass of the "TaskScheduler" class, then you can ignore this message.) I have installed a new version (2010.05.27) of the "LIVE555 Streaming Media" code that changes the "TaskScheduler" API to add new virtual functions "turnOnBackgroundWriteHandling()" and "turnOffBackgroundWriteHandling()" - similar to the existing "Read" functions. These functions are used to test a socket for writability, which is needed to implement asynchronous RTSP 'connect' operations in the new, non-blocking version of the "RTSPClient" interface - which I'll be releasing within a few days. Implementations of these two new virtual functions have been added for "BasicTaskScheduler" - the "TaskScheduler" implementation that we supply in the released code. However, if you have implemented your own subclass of "TaskScheduler", then you will need to write your own implementation of the new virtual functions "turnOnBackgroundWriteHandling()" and "turnOffBackgroundWriteHandling()". I have also made a small change to the signature of the "UsageEnvironment::setResultErrMsg() virtual function, so if you have your own subclass of "UsageEnvironment", you will need to modify your implementation of "setResultErrMsg()" accordingly. This function now takes a second, optional "err" parameter. If non-zero, this error code is used - instead of 'errno' - to determine the error message that's used. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From stephane.saragaglia at robosoft.fr Fri May 28 05:02:13 2010 From: stephane.saragaglia at robosoft.fr (=?ISO-8859-15?Q?St=E9phane_SARAGAGLIA?=) Date: Fri, 28 May 2010 14:02:13 +0200 Subject: [Live-devel] RTP/H264 low latency streaming + source change Message-ID: <4BFFB0C5.4010501@robosoft.fr> Hi all, I am using Live555 libraries to stream H264 video provided by a frame grabber, via RTP (not RTSP). I use VLC and VLC activeX as a RTP/H264 client. Sometimes, I need to change the camera used by the framegrabber, so I close the RTP sink, the framer, the source, and I open them again with the new video. Doing that, (even with the same video parameters), the client often hang (but not every time), and sometimes go on playing again but with a big delay. How can I prevent the client from freezing the video or display the video with delay ? Sending some missing frames ? Special trick to warn client ? My main objective is LOW latency, some image skips are not a problem. Any advice ? (client cannot send data to server, so no rtcp) Regards From finlayson at live555.com Sat May 29 17:46:45 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 May 2010 17:46:45 -0700 Subject: [Live-devel] New, improved "RTSPClient" interface now available Message-ID: RTSPClient: ========== I have installed a new version (2010.05.29) of the "LIVE555 Streaming Media" code that adds the long-promised new 'asynchronous' (i.e., non-blocking) interface to the "RTSPClient" class. Each operation that sends a RTSP command now takes a 'response handler' function as parameter. The operation will immediately (without blocking), but the 'response handler' function will get called later, when a response arrives (or if an error occurs). This will make it practical to open/receive multiple RTSP streams simultaneously, and/or perform other operations concurrently with RTSP client operations. For backwards compatibility, the old 'synchronous' interface still remains, and is implemented using the new 'asynchronous' interface. (Therefore, existing RTSP client applications should not need to be modified - for now.) Note, however, that the old 'synchronous' interface should not be used for new applications, and it will likely be removed in a few months.) For now, the demo application "openRTSP" still uses the old interface, but will be rewritten over the next few weeks to use the new interface. For details, see http://www.live555.com/liveMedia/doxygen/html/RTSPClient_8hh-source.html I have done a lot of testing with this new interface and implementation, but if you find any problems, please let us know. TaskScheduler: ========== Unfortunately I have modified the "TaskScheduler" definition yet again, because I felt it was getting too complicated. There's now just one virtual function for setting/clearing socket handlers: virtual void setBackgroundHandling(int socketNum, int conditionSet, BackgroundHandlerProc* handlerProc, void* clientData) = 0; where "conditionSet" is a combination of the SOCKET_READABLE, SOCKET_WRITABLE, and SOCKET_EXCEPTION flags. If you have your own implementation of "TaskScheduler", then you will need to implement this virtual function - and not the old "turnOn*" and "turnOff*" functions. (For backwards compatibility, however, the existing "turnOnBackgroundReadHandling()" and "turnOffBackgroundReadHandling()" functions are retained, but are now implemented using "setBackgroundHandling()".) For details, see http://www.live555.com/liveMedia/doxygen/html/UsageEnvironment_8hh-source.html -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From a.nemec at atlas.cz Mon May 31 10:05:31 2010 From: a.nemec at atlas.cz (=?UTF-8?B?QWxleGFuZHIgTsSbbWVj?=) Date: Mon, 31 May 2010 19:05:31 +0200 Subject: [Live-devel] MP4V-ES payload Message-ID: <1275325531.714837.8328.nullmailer@mail1003.cent> Dear Ross, just one question regading the MP4V-ES payload (implemented in MPEG4ESVideoRTPSource.cpp), it works very nice for every RFC 3016 compatible MPEG4 video source we have tried. This is a quite simple payload because of the visual stream being mapped directly onto RTP packets with no special header. But the cpp file says on line 25 //##### NOTE: INCOMPLETE!!! #####. In what way is this payload implementation incomplete? Do you only mean some marginal sanity checks or similar or is anything essential missing from the implementation? Thanks Alex From adammich2 at gmail.com Sat May 29 11:03:27 2010 From: adammich2 at gmail.com (Adam Mich) Date: Sat, 29 May 2010 20:03:27 +0200 Subject: [Live-devel] AMRInterleaver has MIMEType() "binary/octed-stream" and InitiateByMediaType() fails ? Message-ID: I'm unable to receive AMR audio using InitiateByMediaType( "audio/AMR"). The reason is readSource(), which is AMRInterleaver in this case, has no MIMEType() redefined. It returns a generic type, something like "binary/octed-stream" instead "audio/AMR", and function fails at this line : // Make sure the source's MIME type is one that we handle: 00482 if (strcmp(subsession ->readSource ()->MIMEtype(), mimeType) != 0) { 00483 if (!wasAlreadyInitiated) subsession ->deInitiate (); 00484 continue; Of course, I'm not sure that I'm doing everything ok, but it looks like a bug to me. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielda at gmx-topmail.de Thu May 27 08:34:05 2010 From: danielda at gmx-topmail.de (danielda at gmx-topmail.de) Date: Thu, 27 May 2010 17:34:05 +0200 Subject: [Live-devel] memory leak using tcp Message-ID: <20100527153405.123310@gmx.net> Hi, i built a RTSP-client with the latest source codes based on the openRTSP-example to receive H.264, MPEG4 and MJPEG-Streams. Using UDP, everything works fine and without memory leaks, but using TCP, there are four small memory leaks as reported earlier by Kamil in the following thread: http://lists.live555.com/pipermail/live-devel/2005-September/003150.html I was wondering, if these described issues have been solved in the course of time? Best regards, Daniel -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From lqfjun at gmail.com Mon May 31 09:54:02 2010 From: lqfjun at gmail.com (QF Lin) Date: Tue, 1 Jun 2010 00:54:02 +0800 Subject: [Live-devel] crackling noise Message-ID: Hi, I m a newbie to this mailing list. Currently, I m looking at streaming audio through rtsp. I m using an older version of the live555 library (built into directshow filter) which is taken from sourceforge. Live555 is excellent in streaming the audio but there is annoying crackling sound. I have tried replacing the files with the latest live555 but the directshow filter can't work. Any pointers how to remedy the crackling sound problem. regards QF -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohitagandotra at gmail.com Sat May 29 06:05:23 2010 From: mohitagandotra at gmail.com (mohita gandotra) Date: Sat, 29 May 2010 18:35:23 +0530 Subject: [Live-devel] RTP Timestamp to UTC time In-Reply-To: References: Message-ID: Hi Ross I am not a casual hobbiest.I am using gmail id because My Official mail-id is not accessible from home. I access Live555 mails from home also. But if you want I will subscribe to the live555 mailing list using my official id. I have more queries regarding timestamp. I don't understand the code in RTPReceptionStats::noteIncomingSR function. The function is written as: void RTPReceptionStats::noteIncomingSR(u_int32_t ntpTimestampMSW, u_int32_t ntpTimestampLSW, u_int32_t rtpTimestamp) { fLastReceivedSR_NTPmsw = ntpTimestampMSW; fLastReceivedSR_NTPlsw = ntpTimestampLSW; gettimeofday(&fLastReceivedSR_time, NULL); // Use this SR to update time synchronization information: fSyncTimestamp = rtpTimestamp; fSyncTime.tv_sec = ntpTimestampMSW - 0x83AA7E80; // 1/1/1900 -> 1/1/1970 double microseconds = (ntpTimestampLSW*15625.0)/0x04000000; // 10^6/2^32 fSyncTime.tv_usec = (unsigned)(microseconds+0.5); fHasBeenSynchronized = True; } I having following confusion: 1. fSyncTime.tv_sec = ntpTimestampMSW - 0x83AA7E80; // 1/1/1900 -> 1/1/1970 why 0x83AA7E80 is subtracted from ntpTimestampMSW? 2. double microseconds = (ntpTimestampLSW*15625.0)/0x04000000; // 10^6/2^32 Why 15625.0 is multiplied with ntpTimestampLSW and the result is divided by 0x04000000 Please reply. On Mon, May 10, 2010 at 10:34 AM, Ross Finlayson wrote: > We are developing a client application using Live555. >> > > Do "we" not have a domain name? (If you use a "@gmail.com" email address, > then you are assumed to be a casual hobbiest (whose posts are moderated and > given a very low-priority), not a "we".) > > > > Our application have some specific requirement of converting the rtp >> timestamp of each video frame to utc time. So I have following query >> regarding this: >> >> 1.The MediaSink class of Live555 gets the presentation time as a parameter >> in aftergettingframe function.This presentation time can be converted to RTP >> timestamp using convertToRTPTimestamp function in RTPSink class.I just want >> to know how this rtp timestamp can be converted to UTC time. >> > > You don't need to know or care about RTP timestamps. Our software > automatically converts from presentation time to RTP timestamp (at the > server end), and then back from RTP timestamp to presentation time (at the > client end). This is assuming, of course, that you use RTCP (which is a > required part of the RTP/RTCP standard). > > So, just make sure that you give your streams proper presentation times at > the server end - and you will get them automatically at the client end. > These presentation times must be aligned with 'wall clock' time - i.e., the > time that you would get by calling "gettimeofday()". (If "gettimeofday()" > does not return UTC time, then you will need to apply the appropriate > conversion at the client end. > -- > > 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 > -- Mohita Gandotra ------------------------------ Senior Software Engineer Canon India Pvt. Ltd., Noida -------------- next part -------------- An HTML attachment was scrubbed... URL: