From cataldi.alessandro at gmail.com Mon Aug 2 04:00:41 2010 From: cataldi.alessandro at gmail.com (Alessandro Cataldi) Date: Mon, 2 Aug 2010 13:00:41 +0200 Subject: [Live-devel] Multi-destination stream relayer Message-ID: Hi Ross, I'd like to use Live555 library and your testProgs as a basis to create the following module: a deamon that is receiving a multicast stream and that accepts requests to relay this stream to multiple unicast destinations. In other words, when the module receives a "new destination request" message, it must be able to stream the content (via unicast) to this new destination and to all previous ones (previously registered). Thanks in advance, Alessandro Cataldi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmed.atef at interact.mobi Tue Aug 3 06:36:50 2010 From: ahmed.atef at interact.mobi (Ahmed Atef) Date: Tue, 3 Aug 2010 16:36:50 +0300 Subject: [Live-devel] problem streaming Mpeg files to Amino settop box using live555 streaming server In-Reply-To: <008901cb2cc9$29baaea0$7d300be0$@atef@interact.mobi> References: <008901cb2cc9$29baaea0$7d300be0$@atef@interact.mobi> Message-ID: <4c581b78.a0ebd80a.69e5.ffffba27@mx.google.com> Dear All Kindly help me as I am trying to stream MPEG file to Amino settop box I found a sample file at your site (wwe.m4e) its an mpeg-4 file and it is working on my PC but when I try to run it on the settop box I got the following error " BasicUDPSink::afterGettingFrame1(): The input frame data was too large for our spcified maximum payload size (1450). 2568 bytes of trailing data was dropped! " Please help me as this is an urgent matter for me. I couldn`t find any Mpeg-1 or MPEG-2 files on your site to stream and the samples I got from the internet didn`t work at all with your streaming server, so please send me some files if this was the problem. Kind Regards Ahmed Atef system Engineer Interact Egypt 7B Omar Shaaban st. Nasr city, Cairo T +202 24149624 F +202 26904981 M +2010 0102058 Adobe Systems From: Ahmed Atef [mailto:ahmed.atef at interact.mobi] Sent: Monday, July 26, 2010 4:48 PM To: live-devel at lists.live555.com Cc: 'Fady Ramzy'; 'Remon Magdy' Subject: problem with the live555 streaming server Dear All I am trying to stream mpg files to amino settop box using the Live555 streaming server but I couldn`t have any stream even when trying to stream from my pc using the quicktime player The player just keep trying to connect and after about a minute it disconnect automatically or the player crashes I tried it from 2 different PCs with no luck. the server keeps displaying these lines : StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 StreamParser::parsePESPacket(): saw inconsistent PES_packet_length 925 < 926 Your fast response is highly appreciated Kind Regards Ahmed Atef system Engineer Interact Egypt 7B Omar Shaaban st. Nasr city, Cairo T +202 24149624 F +202 26904981 M +2010 0102058 Adobe Systems -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1018 bytes Desc: not available URL: From finlayson at live555.com Tue Aug 3 06:54:12 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Aug 2010 06:54:12 -0700 Subject: [Live-devel] problem streaming Mpeg files to Amino settop box using live555 streaming server In-Reply-To: <4c581b78.a0ebd80a.69e5.ffffba27@mx.google.com> References: <008901cb2cc9$29baaea0$7d300be0$@atef@interact.mobi> <4c581b78.a0ebd80a.69e5.ffffba27@mx.google.com> Message-ID: I believe the only kind of data that the Amino settop box will accept is MPEG Transport Stream data. Therefore the only kind of file that you can stream from our servers to such a settop box is a MPEG Transport Stream file. ".m4e" files are *not* MPEG Transport Stream files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ahmed.atef at interact.mobi Tue Aug 3 07:23:00 2010 From: ahmed.atef at interact.mobi (Ahmed Atef) Date: Tue, 3 Aug 2010 17:23:00 +0300 Subject: [Live-devel] problem streaming Mpeg files to Amino settop box using live555 streaming server In-Reply-To: References: <008901cb2cc9$29baaea0$7d300be0$@atef@interact.mobi> <4c581b78.a0ebd80a.69e5.ffffba27@mx.google.com> Message-ID: <4c582648.69e7d80a.7e09.ffffc4bf@mx.google.com> Thank you so much for your fast and professional response. Kind Regards ???? Ahmed Atef ???? system Engineer ???? Interact Egypt ????7B Omar Shaaban st. ???? Nasr city, Cairo ???? T +202? 24149624 ???? F +202? 26904981 ???? M +2010 0102058 -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, August 03, 2010 4:54 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] problem streaming Mpeg files to Amino settop box using live555 streaming server I believe the only kind of data that the Amino settop box will accept is MPEG Transport Stream data. Therefore the only kind of file that you can stream from our servers to such a settop box is a MPEG Transport Stream file. ".m4e" files are *not* MPEG Transport Stream files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From d2 at d2consulting.co.uk Tue Aug 3 07:38:18 2010 From: d2 at d2consulting.co.uk (d2 at d2consulting.co.uk) Date: Tue, 3 Aug 2010 14:38:18 +0000 Subject: [Live-devel] problem streaming Mpeg files to Amino settop boxusing live555 streaming server In-Reply-To: References: <008901cb2cc9$29baaea0$7d300be0$@atef@interact.mobi><4c581b78.a0ebd80a.69e5.ffffba27@mx.google.com> Message-ID: <506065312-1280846295-cardhu_decombobulator_blackberry.rim.net-1757930106-@bda2148.bisx.produk.on.blackberry> For reference they should also support mms / http asf streams from windows media server (using VC-1 encoding). Hth Dom Sent from my BlackBerry? wireless device -----Original Message----- From: Ross Finlayson Sender: live-devel-bounces at ns.live555.com Date: Tue, 3 Aug 2010 06:54:12 To: LIVE555 Streaming Media - development & use Reply-To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] problem streaming Mpeg files to Amino settop box using live555 streaming server I believe the only kind of data that the Amino settop box will accept is MPEG Transport Stream data. Therefore the only kind of file that you can stream from our servers to such a settop box is a MPEG Transport Stream file. ".m4e" files are *not* MPEG Transport Stream files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From ghotspot at gmail.com Tue Aug 3 10:37:18 2010 From: ghotspot at gmail.com (Guy's Hotspot) Date: Tue, 3 Aug 2010 19:37:18 +0200 Subject: [Live-devel] problem streaming Mpeg files to Amino settop box using live555 streaming server In-Reply-To: <4c582648.69e7d80a.7e09.ffffc4bf@mx.google.com> References: <4c581b78.a0ebd80a.69e5.ffffba27@mx.google.com> <4c582648.69e7d80a.7e09.ffffc4bf@mx.google.com> Message-ID: Amino guys are so silent even though I have signed a nda with them. I am trying to set up a demo platform with live555, Aminet 125, VLC ??? Is there a link for a turorial ? Their jmacx is also hard, I will seriously appreciate if someone has an EPG sample. Thanks 2010/8/3 Ahmed Atef > Thank you so much for your fast and professional response. > > Kind Regards > > Ahmed Atef > system Engineer > > Interact Egypt > 7B Omar Shaaban st. > Nasr city, Cairo > > T +202 24149624 > F +202 26904981 > M +2010 0102058 > > > > > -----Original Message----- > From: live-devel-bounces at ns.live555.com > [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson > Sent: Tuesday, August 03, 2010 4:54 PM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] problem streaming Mpeg files to Amino settop box > using live555 streaming server > > I believe the only kind of data that the Amino settop box will accept > is MPEG Transport Stream data. Therefore the only kind of file that > you can stream from our servers to such a settop box is a MPEG > Transport Stream file. > > ".m4e" files are *not* MPEG Transport Stream files. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > _______________________________________________ > 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 snarayanan at a2etechnologies.com Tue Aug 3 14:04:27 2010 From: snarayanan at a2etechnologies.com (Shyam Narayanan) Date: Tue, 3 Aug 2010 14:04:27 -0700 Subject: [Live-devel] RTP over HTTP References: Message-ID: <1B9A9D002C346449A8A14D50C168C84F010C52A2@exchsrvr.A2E.local> Hi LIVE555-ians I have already read the various articles of comparisons of TCP vs UDP for RTP and I understand the differences. What I am looking for is a. Has anyone tried the LIVE555 code running it as a server successfully for RTP over HTTP for compressed live video (such as H.264 coming from a camera - not just playing off a disk and not just uncompresssed video) ? If so, b. What was your experience - did you notice any video quality issues - or any other difference from playing it over UDP ? c. Did you need to make any changes to the LIVE555 code to get this to work or did the existing code base work out of the box ? d. Can I use a generic client such as VLC player to play this stream or would I need to write a program that uses code similar to the OpenRTSP client with -t switch. Regards Shyam -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 3 15:10:00 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Aug 2010 15:10:00 -0700 Subject: [Live-devel] RTP over HTTP In-Reply-To: <1B9A9D002C346449A8A14D50C168C84F010C52A2@exchsrvr.A2E.local> References: <1B9A9D002C346449A8A14D50C168C84F010C52A2@exchsrvr.A2E.local> Message-ID: >I have already read the various articles of comparisons of TCP vs >UDP for RTP and I understand the differences. > >What I am looking for is > >a. Has anyone tried the LIVE555 code running it as a server >successfully for RTP over HTTP Do you really mean "RTP over HTTP"? Our server implementation does not (yet) support "RTP over HTTP". I think you mean "RTP over RTSP". > for compressed live video (such as H.264 coming from a camera - not >just playing off a disk and not just uncompresssed video) ? > >If so, >b. What was your experience - did you notice any video quality >issues - or any other difference from playing it over UDP ? > >c. Did you need to make any changes to the LIVE555 code to get this >to work or did the existing code base work out of the box ? See > >d. Can I use a generic client such as VLC player to play this stream >or would I need to write a program that uses code similar to the >OpenRTSP client with -t switch. You can use VLC. However, if you want to ensure that you always receive the stream via RTP-over-TCP (even it it can also be received via UDP), then you should set the appropriate flag in VLC's "Input & Codecs" Preferences panel. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arang1978 at gmail.com Tue Aug 3 22:48:31 2010 From: arang1978 at gmail.com (Aranganathan Sankaradoss) Date: Wed, 4 Aug 2010 14:48:31 +0900 Subject: [Live-devel] record stream even after restarting server Message-ID: hello Friends, I have integrated the Live555 open source code with my Set top box's source code. My set top box could receive the RTSP stream and I could pass it to the demux in Set top box and I could see the video. If the RTSP server is restarted then in that case, I could not receive the stream from my Set top box. How to recover getting data from server, even after the server gets restarted? Regards, Arang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamj01 at hotmail.com Fri Aug 6 13:47:09 2010 From: tamj01 at hotmail.com (John Tam) Date: Fri, 6 Aug 2010 16:47:09 -0400 Subject: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client Message-ID: Hello, I am using the RTSP server functionality of the LiveMedia library, and I might have resolved a client session management issue. The senario is when a ServerMediaSubsession is shared [reuseFirstSource=True] and clients choose RTP-over-TCP for streaming mode, only the last requested RTP-over-TCP RTSPClientSession can be torn down. All of the objects under the ServerMediaSession will be runaways. The MediaSink keeps playing, and the RTPInstance writes with socket error. The stderr shows socket write attempts after all of the RTSP clients are closed. I am trying to limit the scope of the impacted code, and there seems to be two area in the RTPInstance.cpp that are contributing to the problem. #1, The RTPInterface::setServerRequestAlternativeByteHandler() function is overwriting the handler and clientData of an already assigned SocketDescriptor object. It makes all existing socket descriptor of the server media subsession to map to the latest RTSPClientSession instance. #2, When RTCPInstance::addStreamSocket() function adds a new stream channel, the RTPInterface::stopNetworkReading() function calls deregisterSocket() and wipes out the existing SocketDescriptor to RTSPClientSession mapping. Therefore, only the last newly added SocketDescriptor has a valid fServerRequestAlternativeByteHandler to notify of RTSP TEARDOWN command. I have not updated myself to the latest, but I am only working on an older version of the LiveMedia library from March 16, 2010. I think my proposed fix should not have any conflict with the latest code base. The changes are as the following: 1a) Test before overwriting an assigned handler. void RTPInterface::setServerRequestAlternativeByteHandler(ServerRequestAlternativeByteHandler* handler, void* clientData) { for (tcpStreamRecord* streams = fTCPStreams; streams != NULL; streams = streams->fNext) { // Get (or create, if necessary) a socket descriptor for "streams->fStreamSocketNum": SocketDescriptor* socketDescriptor = lookupSocketDescriptor(envir(), streams->fStreamSocketNum); if (! socketDescriptor->hasServerRequestAlternativeByteHandler()) { // Assign a handler & clientData only when there has not been one to avoid mixing up the TCP socket with the intended RTSPClientSession object from RTSPClientSession::handleCmd_PLAY(). socketDescriptor->setServerRequestAlternativeByteHandler(handler, clientData); } } } 1b) Add a new public method to determine if a handler has been already installed. Boolean SocketDescriptor::hasServerRequestAlternativeByteHandler() const { return NULL != fServerRequestAlternativeByteHandler; } 2a) Preserve the mapping of handler of existing TCP client. void RTPInterface::stopNetworkReading() { // Normal case envir().taskScheduler().turnOffBackgroundReadHandling(fGS->socketNum()); // Also turn off read handling on each of our TCP connections: for (tcpStreamRecord* streams = fTCPStreams; streams != NULL; streams = streams->fNext) { // Do not deregister because the RTP interface will lose the handler and clientData inside the SocketDescriptor. // Instead simply stop reading of the socket by turning off the read handler. envir().taskScheduler().turnOffBackgroundReadHandling(streams->fStreamSocketNum); } } 2b) Register new TCP client or renew the socket handler of an existing TCP client. void RTPInterface ::startNetworkReading(TaskScheduler::BackgroundHandlerProc* handlerProc) { // Normal case: Arrange to read UDP packets: envir().taskScheduler(). turnOnBackgroundReadHandling(fGS->socketNum(), handlerProc, fOwner); // Also, receive RTP over TCP, on each of our TCP connections: fReadHandlerProc = handlerProc; for (tcpStreamRecord* streams = fTCPStreams; streams != NULL; streams = streams->fNext) { // Get a socket descriptor for "streams->fStreamSocketNum": SocketDescriptor* socketDescriptor = lookupSocketDescriptor(envir(), streams->fStreamSocketNum); // Restart a previously stopped stock read handler or start a new one if (NULL != socketDescriptor->lookupRTPInterface(streams->fStreamChannelId)) { socketDescriptor->reregisterRTPInterface(); } else { // Tell it about our subChannel: socketDescriptor->registerRTPInterface(streams->fStreamChannelId, this); } } } Cheers, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Aug 8 06:33:50 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 8 Aug 2010 06:33:50 -0700 Subject: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client In-Reply-To: References: Message-ID: >I have not updated myself to the latest, but I am only working on an >older version of the LiveMedia library from March 16, 2010. Sorry, but no support is given for old versions of the code. There have been significant changes to the code (including to RTP-over-TCP handling) since then. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jefferychi at ingrasys.com Sun Aug 8 20:00:38 2010 From: jefferychi at ingrasys.com (Jeffery Chi) Date: Mon, 9 Aug 2010 11:00:38 +0800 Subject: [Live-devel] openRTSP using problem Message-ID: Dear I met one issue and I can't explain it. Could your give me a hand? I have tried to use openRTSP to received eight 1.3M IPCAMs on a Marvell host chip. I have chosen both UDP and TCP for RTP transmission. But the CPU usage is quite different between UDP and TCP. UDP took almost 99% CPU resource on receiving eight 1.3M IPCAM H.264 streams, but TCP only took 30% CPU resource I can't figure out why it happened. Have you met it before, or it's just a correct performance cost? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinhua.li at siemens.com Mon Aug 9 00:30:56 2010 From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S) Date: Mon, 9 Aug 2010 15:30:56 +0800 Subject: [Live-devel] Can RTCP control bitrate according to netwrok quality? Message-ID: <68D227E48F4B0F4EB6161523402601BE6CE747@PEKW987A.cn001.siemens.net> Dear all, I have implemented a VOD based on live555 via unicast, now I want to know how RTCP control bitrate according to network quality, this means, if network is very bad between server and client, RTCP can reduce bitrate automatically until network is becoming good. How should I do? Thank you in advance~ Best regards. -------------------------------------------------------------- ??? Li Yinhua SIEMENS Siemens Ltd., China Nanjing Branch Corporate Technology Development Center (CT DC), Nanjing 5F Dong Heng International Building Tel.: +86 (25) 52129888 - 6760 Fax: +86 (25) 52129308 Mobile: +86 15895967085 mailto:yinhua.li at siemens.com www.siemens.com P Save a tree. Don't print this e-mail unless it's really necessary. IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person. In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????Tell us???????www.siemens.com.cn/compliancehelpdesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From embedded at gmail.com Mon Aug 9 02:10:50 2010 From: embedded at gmail.com (S.W Hwang) Date: Mon, 9 Aug 2010 18:10:50 +0900 Subject: [Live-devel] Live555 Library based H.264 Streaming Server Connection Problem. Message-ID: Hi. I've been written some code to make a H.264 streaming server. The server is running on Embedded Device (arm linux). The embedded device has H.264 hardware encoder. I attached some code which is initializing the streaming server. On the other hands, I used VLC player in Linux version. I have problems with below code. VLC player is possible to access the H.264 streaming server. But, H.264 streaming server send a message which is "Reply: RTSP/1.0 461 Unsupported Transport". I got a some hint that is "my source code is for H.264 muliticasting streaming server." 1. I want to make a Unicast streaming server. I don't know how to make a Unicast Streaming server with live555 library. Would you tell me how to make it? I have one more question about H.264 encoding data. 2. After H.264 encoding, Do I need another job to send H.264 through RTP/RTSP protocol? //////////////////////////////////////// log message ///////////////////////////////// Play this stream using the URL "rtsp://192.168.10.10:8554/testStream" Beginning streaming... constructing an x264 StreamFramer:411824 ------------------------- ///////////////////////////////////////// Main Code /////////////////////////////////////////////////// int mServerPort = 8000; mEventLoopController = 0; // Begin by setting up our usage environment: mScheduler = BasicTaskScheduler::createNew(); mEnv = BasicUsageEnvironment::createNew(*mScheduler); const unsigned estimatedSessionBandwidth = DEFAULT_RTP_BANDWIDTH_KBPS; // in kbps; for RTCP b/w share const unsigned maxCNAMElen = 100; unsigned char CNAME[maxCNAMElen + 1]; gethostname((char*) CNAME, maxCNAMElen); CNAME[maxCNAMElen] = '\0'; // just in case printf("gethostname=%s", CNAME); // Create 'groupsocks' for RTP and RTCP: const unsigned short rtpPortNum = mServerPort; const unsigned short rtcpPortNum = rtpPortNum + 1; const unsigned char ttl = DEFAULT_RTP_TTL; // low, in case routers don't admin scope struct in_addr destinationAddress; destinationAddress.s_addr = our_inet_addr("192.168.10.10"); //put in destination IP mRtpPort = new Port(rtpPortNum); mRtcpPort = new Port(rtcpPortNum); mRtpGroupsock = new Groupsock(*mEnv, destinationAddress, *mRtpPort, ttl); mRtcpGroupsock = new Groupsock(*mEnv, destinationAddress, *mRtcpPort, ttl); // Create an 'H264 Video RTP' sink from the RTP 'groupsock': mVideoSenderSink = H264VideoRTPSink::createNew(*mEnv, mRtpGroupsock, 96, 0x41, "H264"); // Create (and start) a 'RTCP instance' for this RTP sink: mRtcpInstance = RTCPInstance::createNew(*mEnv, mRtcpGroupsock, estimatedSessionBandwidth, CNAME, mVideoSenderSink, NULL, true); // Note: This starts RTCP running automatically RTSPServer* rtspServer = RTSPServer::createNew(*mEnv, 8554); if (rtspServer == NULL) { *mEnv << "Failed to create RTSP server: " << mEnv->getResultMsg() << "\n"; exit(1); } ServerMediaSession* sms = ServerMediaSession::createNew(*mEnv, "testStream", "embedded", "embedded", true); sms->addSubsession(PassiveServerMediaSubsession::createNew(*mVideoSenderSink, mRtcpInstance)); rtspServer->addServerMediaSession(sms); char* url = rtspServer->rtspURL(sms); *mEnv << "Play this stream using the URL \"" << url << "\"\n"; delete[] url; // Finally, start the streaming: *mEnv << "Beginning streaming...\n"; // Create a framer for the Video Elementary Stream: //StreamFramer does not need a source, it gets the AUs from a buffer queue mVideoSenderSource = x264VideoStreamFramer::createNew(*mEnv, NULL); mVideoSenderSink->startPlaying(*mVideoSenderSource, AfterPlaying, mVideoSenderSink); //schedule the dummy task ScheduleDummyTask(); //does not return until mEvenLoopController = none-zero value mEnv->taskScheduler().doEventLoop(&mEventLoopController); ///////////////////////////////////////// Main Code End /////////////////////////////////////////////////// x264VideoStreamFramer::doGetNextFrame() { /////// H.264 Encoding /////////// .............. //////////// the Encoded data -> insert -> buffer /////////////////////// /////////////////////////////////////////////////////////// unsigned char* pInputBuffer = (unsigned char*) encoded_buf; //this is the size of data to be sent unsigned int sizeBytes = encoded_size; if (sizeBytes < fMaxSize) { memcpy(fTo, pInputBuffer, sizeBytes); } else { //this probably does not work! memcpy(fTo, pInputBuffer, fMaxSize); fNumTruncatedBytes = sizeBytes - fMaxSize; } fFrameSize = sizeBytes; afterGetting(this); } //////////////////////////////////////////// Packet ////////////////////////////////////////////////////////////////////////////////// 192.168.10.4 ( Linux PC / Client) 192.168.10.10 ( Embedded Linux / H.264 Streaming Server ) No. Time Source Destination Protocol Info 6 2.931202 192.168.10.4 192.168.10.10 TCP 36236 > rtsp-alt [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=29313998 TSER=0 WS=6 7 2.931892 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=1773694 TSER=29313998 WS=1 8 2.931936 192.168.10.4 192.168.10.10 TCP 36236 > rtsp-alt [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=29313999 TSER=1773694 9 2.931958 192.168.10.4 192.168.10.10 RTSP OPTIONS rtsp://192.168.10.10:8554/testStream RTSP/1.0 Frame 9 (202 bytes on wire, 202 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) Transmission Control Protocol, Src Port: 36236 (36236), Dst Port: rtsp-alt (8554), Seq: 1, Ack: 1, Len: 134 Real Time Streaming Protocol Request: OPTIONS rtsp://192.168.10.10:8554/testStream RTSP/1.0\r\n Method: OPTIONS URL: rtsp://192.168.10.10:8554/testStream CSeq: 1\r\n User-Agent: VLC media player (LIVE555 Streaming Media v2010.04.09)\r\n \r\n No. Time Source Destination Protocol Info 10 2.932628 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [ACK] Seq=1 Ack=135 Win=6864 Len=0 TSV=1773695 TSER=29313999 11 2.957192 192.168.10.10 192.168.10.4 RTSP Reply: RTSP/1.0 200 OK Frame 11 (220 bytes on wire, 220 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.10 (192.168.10.10), Dst: 192.168.10.4 (192.168.10.4) Transmission Control Protocol, Src Port: rtsp-alt (8554), Dst Port: 36236 (36236), Seq: 1, Ack: 135, Len: 152 Real Time Streaming Protocol Response: RTSP/1.0 200 OK\r\n Status: 200 CSeq: 1\r\n Date: Thu, Jan 01 1970 02:32:48 GMT\r\n Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER\r\n \r\n No. Time Source Destination Protocol Info 12 2.957245 192.168.10.4 192.168.10.10 TCP 36236 > rtsp-alt [ACK] Seq=135 Ack=153 Win=6912 Len=0 TSV=29314024 TSER=1773699 13 2.957634 192.168.10.4 192.168.10.10 RTSP DESCRIBE rtsp://192.168.10.10:8554/testStream RTSP/1.0 Frame 13 (228 bytes on wire, 228 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) Transmission Control Protocol, Src Port: 36236 (36236), Dst Port: rtsp-alt (8554), Seq: 135, Ack: 153, Len: 160 Real Time Streaming Protocol Request: DESCRIBE rtsp://192.168.10.10:8554/testStream RTSP/1.0\r\n Method: DESCRIBE URL: rtsp://192.168.10.10:8554/testStream CSeq: 2\r\n Accept: application/sdp\r\n User-Agent: VLC media player (LIVE555 Streaming Media v2010.04.09)\r\n \r\n No. Time Source Destination Protocol Info 15 2.997117 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [ACK] Seq=153 Ack=295 Win=7936 Len=0 TSV=1773708 TSER=29314025 16 3.009620 192.168.10.10 192.168.10.4 RTSP/SDP Reply: RTSP/1.0 200 OK, with session description[Malformed Packet] Frame 16 (746 bytes on wire, 746 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.10 (192.168.10.10), Dst: 192.168.10.4 (192.168.10.4) Transmission Control Protocol, Src Port: rtsp-alt (8554), Dst Port: 36236 (36236), Seq: 153, Ack: 295, Len: 678 Real Time Streaming Protocol Response: RTSP/1.0 200 OK\r\n Status: 200 CSeq: 2\r\n Date: Thu, Jan 01 1970 02:32:48 GMT\r\n Content-Base: rtsp://192.168.10.10:8554/testStream/\r\n Content-type: application/sdp Content-length: 508 \r\n Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 9109105913 1 IN IP4 192.168.10.10 Owner Username: - Session ID: 9109105913 Session Version: 1 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.10.10 Session Name (s): Session streamed by frank Session Information (i): frank Time Description, active time (t): 0 0 Session Attribute (a): tool:LIVE555 Streaming Media v2010.07.29 Session Attribute (a): type:broadcast Session Attribute (a): control:* Session Attribute (a): source-filter: incl IN IP4 * 192.168.10.10 Session Attribute (a): rtcp-unicast: reflection Session Attribute (a): range:npt=0- Session Attribute (a): x-qt-text-nam:Session streamed by frank Session Attribute (a): x-qt-text-inf:frank Media Description, name and address (m): video 8000 RTP/AVP 96 Connection Information (c): IN IP4 192.168.10.10/255 Bandwidth Information (b): AS:4500 Media Attribute (a): rtpmap:96 H264/90000 Media Attribute (a): fmtp:96 packetization-mode=1;profile-level-id=000041;sprop-parameter-sets=H264 [Malformed Packet: SDP] Frame (746 bytes): 0000 00 00 00 01 00 06 00 4a 5c 26 0a 5b 00 00 08 00 .......J\&.[.... 0010 45 00 02 da d0 1c 40 00 40 06 d2 a2 c0 a8 0a 0a E..... at .@....... 0020 c0 a8 0a 04 21 6a 8d 8c 40 e8 c0 fe 3f 5b c9 0e ....!j.. at ...?[.. 0030 80 18 0f 80 76 73 00 00 01 01 08 0a 00 1b 10 8e ....vs.......... 0040 01 bf 4b e9 52 54 53 50 2f 31 2e 30 20 32 30 30 ..K.RTSP/1.0 200 0050 20 4f 4b 0d 0a 43 53 65 71 3a 20 32 0d 0a 44 61 OK..CSeq: 2..Da 0060 74 65 3a 20 54 68 75 2c 20 4a 61 6e 20 30 31 20 te: Thu, Jan 01 0070 31 39 37 30 20 30 32 3a 33 32 3a 34 38 20 47 4d 1970 02:32:48 GM 0080 54 0d 0a 43 6f 6e 74 65 6e 74 2d 42 61 73 65 3a T..Content-Base: 0090 20 72 74 73 70 3a 2f 2f 31 39 32 2e 31 36 38 2e rtsp://192.168. 00a0 31 30 2e 31 30 3a 38 35 35 34 2f 74 65 73 74 53 10.10:8554/testS 00b0 74 72 65 61 6d 2f 0d 0a 43 6f 6e 74 65 6e 74 2d tream/..Content- 00c0 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f Type: applicatio 00d0 6e 2f 73 64 70 0d 0a 43 6f 6e 74 65 6e 74 2d 4c n/sdp..Content-L 00e0 65 6e 67 74 68 3a 20 35 30 38 0d 0a 0d 0a 76 3d ength: 508....v= 00f0 30 0d 0a 6f 3d 2d 20 39 31 30 39 31 30 35 39 31 0..o=- 910910591 0100 33 20 31 20 49 4e 20 49 50 34 20 31 39 32 2e 31 3 1 IN IP4 192.1 0110 36 38 2e 31 30 2e 31 30 0d 0a 73 3d 53 65 73 73 68.10.10..s=Sess 0120 69 6f 6e 20 73 74 72 65 61 6d 65 64 20 62 79 20 ion streamed by 0130 66 72 61 6e 6b 0d 0a 69 3d 66 72 61 6e 6b 0d 0a frank..i=frank.. 0140 74 3d 30 20 30 0d 0a 61 3d 74 6f 6f 6c 3a 4c 49 t=0 0..a=tool:LI 0150 56 45 35 35 35 20 53 74 72 65 61 6d 69 6e 67 20 VE555 Streaming 0160 4d 65 64 69 61 20 76 32 30 31 30 2e 30 37 2e 32 Media v2010.07.2 0170 39 0d 0a 61 3d 74 79 70 65 3a 62 72 6f 61 64 63 9..a=type:broadc 0180 61 73 74 0d 0a 61 3d 63 6f 6e 74 72 6f 6c 3a 2a ast..a=control:* 0190 0d 0a 61 3d 73 6f 75 72 63 65 2d 66 69 6c 74 65 ..a=source-filte 01a0 72 3a 20 69 6e 63 6c 20 49 4e 20 49 50 34 20 2a r: incl IN IP4 * 01b0 20 31 39 32 2e 31 36 38 2e 31 30 2e 31 30 0d 0a 192.168.10.10.. 01c0 61 3d 72 74 63 70 2d 75 6e 69 63 61 73 74 3a 20 a=rtcp-unicast: 01d0 72 65 66 6c 65 63 74 69 6f 6e 0d 0a 61 3d 72 61 reflection..a=ra 01e0 6e 67 65 3a 6e 70 74 3d 30 2d 0d 0a 61 3d 78 2d nge:npt=0-..a=x- 01f0 71 74 2d 74 65 78 74 2d 6e 61 6d 3a 53 65 73 73 qt-text-nam:Sess 0200 69 6f 6e 20 73 74 72 65 61 6d 65 64 20 62 79 20 ion streamed by 0210 66 72 61 6e 6b 0d 0a 61 3d 78 2d 71 74 2d 74 65 frank..a=x-qt-te 0220 78 74 2d 69 6e 66 3a 66 72 61 6e 6b 0d 0a 6d 3d xt-inf:frank..m= 0230 76 69 64 65 6f 20 38 30 30 30 20 52 54 50 2f 41 video 8000 RTP/A 0240 56 50 20 39 36 0d 0a 63 3d 49 4e 20 49 50 34 20 VP 96..c=IN IP4 0250 31 39 32 2e 31 36 38 2e 31 30 2e 31 30 2f 32 35 192.168.10.10/25 0260 35 0d 0a 62 3d 41 53 3a 34 35 30 30 0d 0a 61 3d 5..b=AS:4500..a= 0270 72 74 70 6d 61 70 3a 39 36 20 48 32 36 34 2f 39 rtpmap:96 H264/9 0280 30 30 30 30 0d 0a 61 3d 66 6d 74 70 3a 39 36 20 0000..a=fmtp:96 0290 70 61 63 6b 65 74 69 7a 61 74 69 6f 6e 2d 6d 6f packetization-mo 02a0 64 65 3d 31 3b 70 72 6f 66 69 6c 65 2d 6c 65 76 de=1;profile-lev 02b0 65 6c 2d 69 64 3d 30 30 30 30 34 31 3b 73 70 72 el-id=000041;spr 02c0 6f 70 2d 70 61 72 61 6d 65 74 65 72 2d 73 65 74 op-parameter-set 02d0 73 3d 48 32 36 34 0d 0a 61 3d 63 6f 6e 74 72 6f s=H264..a=contro 02e0 6c 3a 74 72 61 63 6b 31 0d 0a l:track1.. ASCII bytes to tvb (3 bytes): 0000 00 00 41 ..A h264 prop-parameter-sets (3 bytes): 0000 1f 6e b8 .n. No. Time Source Destination Protocol Info 17 3.011104 192.168.10.4 192.168.10.10 RTSP SETUP rtsp://192.168.10.10:8554/testStream/track1 RTSP/1.0 18 3.011799 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [ACK] Seq=831 Ack=484 Win=9008 Len=0 TSV=1773710 TSER=29314078 19 3.060406 192.168.10.10 192.168.10.4 RTSP Reply: RTSP/1.0 200 OK 20 3.061527 192.168.10.4 192.168.10.10 RTSP PLAY rtsp://192.168.10.10:8554/testStream/ RTSP/1.0 21 3.062252 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [ACK] Seq=1015 Ack=654 Win=10080 Len=0 TSV=1773721 TSER=29314129 24 3.112507 192.168.10.10 192.168.10.4 RTSP Reply: RTSP/1.0 200 OK Frame 24 (256 bytes on wire, 256 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.10 (192.168.10.10), Dst: 192.168.10.4 (192.168.10.4) Transmission Control Protocol, Src Port: rtsp-alt (8554), Dst Port: 36236 (36236), Seq: 1015, Ack: 654, Len: 188 Real Time Streaming Protocol Response: RTSP/1.0 200 OK\r\n Status: 200 CSeq: 4\r\n Date: Thu, Jan 01 1970 02:32:48 GMT\r\n Range: npt=0.000-\r\n Session: 33E6825D RTP-Info: url=rtsp:// 192.168.10.10:8554/testStream/track1;seq=7610;rtptime=35150190\r\n \r\n No. Time Source Destination Protocol Info 25 3.117616 192.168.10.4 192.168.10.10 RTSP GET_PARAMETER rtsp://192.168.10.10:8554/testStream/ RTSP/1.0 26 3.118293 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [ACK] Seq=1203 Ack=814 Win=11152 Len=0 TSV=1773732 TSER=29314185 27 3.163629 192.168.10.10 192.168.10.4 RTSP Reply: RTSP/1.0 200 OK 28 3.203476 192.168.10.4 192.168.10.10 TCP 36236 > rtsp-alt [ACK] Seq=814 Ack=1287 Win=11008 Len=0 TSV=29314271 TSER=1773740 32 5.813108 192.168.10.4 192.168.10.10 RTCP Receiver Report Source description Frame 32 (68 bytes on wire, 68 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) User Datagram Protocol, Src Port: vcom-tunnel (8001), Dst Port: vcom-tunnel (8001) Real-time Transport Control Protocol (Receiver Report) [Stream setup by RTSP (frame 17)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0000 = Reception report count: 0 Packet type: Receiver Report (201) Length: 1 (8 bytes) Sender SSRC: 0xcd6b4254 (3446358612) Real-time Transport Control Protocol (Source description) [Stream setup by RTSP (frame 17)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0001 = Source count: 1 Packet type: Source description (202) Length: 3 (16 bytes) Chunk 1, SSRC/CSRC 0xCD6B4254 [RTCP frame length check: OK - 24 bytes] 0000 00 04 00 01 00 06 00 13 77 c9 c3 7c 00 00 08 00 ........w..|.... 0010 45 00 00 34 00 00 40 00 40 11 a5 5a c0 a8 0a 04 E..4.. at .@..Z.... 0020 c0 a8 0a 0a 1f 41 1f 41 00 20 9c 46 80 c9 00 01 .....A.A. .F.... 0030 cd 6b 42 54 81 ca 00 03 cd 6b 42 54 01 02 6c 6c .kBT.....kBT..ll 0040 00 00 00 00 .... No. Time Source Destination Protocol Info 51 11.179855 192.168.10.4 192.168.10.10 RTCP Receiver Report Source description Frame 51 (68 bytes on wire, 68 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) User Datagram Protocol, Src Port: vcom-tunnel (8001), Dst Port: vcom-tunnel (8001) Real-time Transport Control Protocol (Receiver Report) [Stream setup by RTSP (frame 17)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0000 = Reception report count: 0 Packet type: Receiver Report (201) Length: 1 (8 bytes) Sender SSRC: 0xcd6b4254 (3446358612) Real-time Transport Control Protocol (Source description) [Stream setup by RTSP (frame 17)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0001 = Source count: 1 Packet type: Source description (202) Length: 3 (16 bytes) Chunk 1, SSRC/CSRC 0xCD6B4254 [RTCP frame length check: OK - 24 bytes] 0000 00 04 00 01 00 06 00 13 77 c9 c3 7c 00 00 08 00 ........w..|.... 0010 45 00 00 34 00 00 40 00 40 11 a5 5a c0 a8 0a 04 E..4.. at .@..Z.... 0020 c0 a8 0a 0a 1f 41 1f 41 00 20 9c 46 80 c9 00 01 .....A.A. .F.... 0030 cd 6b 42 54 81 ca 00 03 cd 6b 42 54 01 02 6c 6c .kBT.....kBT..ll 0040 00 00 00 00 .... No. Time Source Destination Protocol Info 60 13.675365 192.168.10.4 192.168.10.10 RTSP TEARDOWN rtsp://192.168.10.10:8554/testStream/ RTSP/1.0 Frame 60 (223 bytes on wire, 223 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) Transmission Control Protocol, Src Port: 36236 (36236), Dst Port: rtsp-alt (8554), Seq: 814, Ack: 1287, Len: 155 Real Time Streaming Protocol Request: TEARDOWN rtsp://192.168.10.10:8554/testStream/ RTSP/1.0\r\n Method: TEARDOWN URL: rtsp://192.168.10.10:8554/testStream/ CSeq: 6\r\n Session: 33E6825D User-Agent: VLC media player (LIVE555 Streaming Media v2010.04.09)\r\n \r\n No. Time Source Destination Protocol Info 61 13.676098 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [ACK] Seq=1287 Ack=969 Win=12224 Len=0 TSV=1775843 TSER=29324742 62 13.681997 192.168.10.10 192.168.10.4 RTSP Reply: RTSP/1.0 200 OK 63 13.682013 192.168.10.4 192.168.10.10 TCP 36236 > rtsp-alt [ACK] Seq=969 Ack=1352 Win=11008 Len=0 TSV=29324749 TSER=1775845 64 13.682021 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [FIN, ACK] Seq=1352 Ack=969 Win=12224 Len=0 TSV=1775845 TSER=29324742 65 13.682330 192.168.10.4 192.168.10.10 RTCP Receiver Report Goodbye 66 13.682391 192.168.10.4 192.168.10.10 TCP 36236 > rtsp-alt [FIN, ACK] Seq=969 Ack=1353 Win=11008 Len=0 TSV=29324749 TSER=1775845 67 13.682493 192.168.10.4 192.168.10.10 TCP 36237 > rtsp-alt [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=29324750 TSER=0 WS=6 68 13.682956 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36236 [ACK] Seq=1353 Ack=970 Win=12224 Len=0 TSV=1775845 TSER=29324749 69 13.683386 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36237 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=1775845 TSER=29324750 WS=1 70 13.683407 192.168.10.4 192.168.10.10 TCP 36237 > rtsp-alt [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=29324750 TSER=1775845 71 13.683425 192.168.10.4 192.168.10.10 RTSP OPTIONS rtsp://192.168.10.10:8554/testStream RTSP/1.0 Frame 71 (202 bytes on wire, 202 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) Transmission Control Protocol, Src Port: 36237 (36237), Dst Port: rtsp-alt (8554), Seq: 1, Ack: 1, Len: 134 Real Time Streaming Protocol Request: OPTIONS rtsp://192.168.10.10:8554/testStream RTSP/1.0\r\n Method: OPTIONS URL: rtsp://192.168.10.10:8554/testStream CSeq: 1\r\n User-Agent: VLC media player (LIVE555 Streaming Media v2010.04.09)\r\n \r\n No. Time Source Destination Protocol Info 72 13.684104 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36237 [ACK] Seq=1 Ack=135 Win=6864 Len=0 TSV=1775845 TSER=29324750 73 13.735277 192.168.10.10 192.168.10.4 RTSP Reply: RTSP/1.0 200 OK Frame 73 (220 bytes on wire, 220 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.10 (192.168.10.10), Dst: 192.168.10.4 (192.168.10.4) Transmission Control Protocol, Src Port: rtsp-alt (8554), Dst Port: 36237 (36237), Seq: 1, Ack: 135, Len: 152 Real Time Streaming Protocol Response: RTSP/1.0 200 OK\r\n Status: 200 CSeq: 1\r\n Date: Thu, Jan 01 1970 02:32:59 GMT\r\n Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER\r\n \r\n No. Time Source Destination Protocol Info 74 13.735296 192.168.10.4 192.168.10.10 TCP 36237 > rtsp-alt [ACK] Seq=135 Ack=153 Win=6912 Len=0 TSV=29324802 TSER=1775855 75 13.735981 192.168.10.4 192.168.10.10 RTSP DESCRIBE rtsp://192.168.10.10:8554/testStream RTSP/1.0 Frame 75 (228 bytes on wire, 228 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) Transmission Control Protocol, Src Port: 36237 (36237), Dst Port: rtsp-alt (8554), Seq: 135, Ack: 153, Len: 160 Real Time Streaming Protocol Request: DESCRIBE rtsp://192.168.10.10:8554/testStream RTSP/1.0\r\n Method: DESCRIBE URL: rtsp://192.168.10.10:8554/testStream CSeq: 2\r\n Accept: application/sdp\r\n User-Agent: VLC media player (LIVE555 Streaming Media v2010.04.09)\r\n \r\n No. Time Source Destination Protocol Info 76 13.736574 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36237 [ACK] Seq=153 Ack=295 Win=7936 Len=0 TSV=1775856 TSER=29324803 77 13.787707 192.168.10.10 192.168.10.4 RTSP/SDP Reply: RTSP/1.0 200 OK, with session description[Malformed Packet] Frame 77 (746 bytes on wire, 746 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.10 (192.168.10.10), Dst: 192.168.10.4 (192.168.10.4) Transmission Control Protocol, Src Port: rtsp-alt (8554), Dst Port: 36237 (36237), Seq: 153, Ack: 295, Len: 678 Real Time Streaming Protocol Response: RTSP/1.0 200 OK\r\n Status: 200 CSeq: 2\r\n Date: Thu, Jan 01 1970 02:32:59 GMT\r\n Content-Base: rtsp://192.168.10.10:8554/testStream/\r\n Content-type: application/sdp Content-length: 508 \r\n Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 9109105913 1 IN IP4 192.168.10.10 Owner Username: - Session ID: 9109105913 Session Version: 1 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.10.10 Session Name (s): Session streamed by frank Session Information (i): frank Time Description, active time (t): 0 0 Session Attribute (a): tool:LIVE555 Streaming Media v2010.07.29 Session Attribute (a): type:broadcast Session Attribute (a): control:* Session Attribute (a): source-filter: incl IN IP4 * 192.168.10.10 Session Attribute (a): rtcp-unicast: reflection Session Attribute (a): range:npt=0- Session Attribute (a): x-qt-text-nam:Session streamed by frank Session Attribute (a): x-qt-text-inf:frank Media Description, name and address (m): video 8000 RTP/AVP 96 Connection Information (c): IN IP4 192.168.10.10/255 Bandwidth Information (b): AS:4500 Media Attribute (a): rtpmap:96 H264/90000 Media Attribute (a): fmtp:96 packetization-mode=1;profile-level-id=000041;sprop-parameter-sets=H264 [Malformed Packet: SDP] Frame (746 bytes): 0000 00 00 00 01 00 06 00 4a 5c 26 0a 5b 00 00 08 00 .......J\&.[.... 0010 45 00 02 da 4c 07 40 00 40 06 56 b8 c0 a8 0a 0a E...L. at .@.V..... 0020 c0 a8 0a 04 21 6a 8d 8d 41 3d 55 79 49 63 c5 cc ....!j..A=UyIc.. 0030 80 18 0f 80 a7 56 00 00 01 01 08 0a 00 1b 18 f9 .....V.......... 0040 01 bf 76 03 52 54 53 50 2f 31 2e 30 20 32 30 30 ..v.RTSP/1.0 200 0050 20 4f 4b 0d 0a 43 53 65 71 3a 20 32 0d 0a 44 61 OK..CSeq: 2..Da 0060 74 65 3a 20 54 68 75 2c 20 4a 61 6e 20 30 31 20 te: Thu, Jan 01 0070 31 39 37 30 20 30 32 3a 33 32 3a 35 39 20 47 4d 1970 02:32:59 GM 0080 54 0d 0a 43 6f 6e 74 65 6e 74 2d 42 61 73 65 3a T..Content-Base: 0090 20 72 74 73 70 3a 2f 2f 31 39 32 2e 31 36 38 2e rtsp://192.168. 00a0 31 30 2e 31 30 3a 38 35 35 34 2f 74 65 73 74 53 10.10:8554/testS 00b0 74 72 65 61 6d 2f 0d 0a 43 6f 6e 74 65 6e 74 2d tream/..Content- 00c0 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f Type: applicatio 00d0 6e 2f 73 64 70 0d 0a 43 6f 6e 74 65 6e 74 2d 4c n/sdp..Content-L 00e0 65 6e 67 74 68 3a 20 35 30 38 0d 0a 0d 0a 76 3d ength: 508....v= 00f0 30 0d 0a 6f 3d 2d 20 39 31 30 39 31 30 35 39 31 0..o=- 910910591 0100 33 20 31 20 49 4e 20 49 50 34 20 31 39 32 2e 31 3 1 IN IP4 192.1 0110 36 38 2e 31 30 2e 31 30 0d 0a 73 3d 53 65 73 73 68.10.10..s=Sess 0120 69 6f 6e 20 73 74 72 65 61 6d 65 64 20 62 79 20 ion streamed by 0130 66 72 61 6e 6b 0d 0a 69 3d 66 72 61 6e 6b 0d 0a frank..i=frank.. 0140 74 3d 30 20 30 0d 0a 61 3d 74 6f 6f 6c 3a 4c 49 t=0 0..a=tool:LI 0150 56 45 35 35 35 20 53 74 72 65 61 6d 69 6e 67 20 VE555 Streaming 0160 4d 65 64 69 61 20 76 32 30 31 30 2e 30 37 2e 32 Media v2010.07.2 0170 39 0d 0a 61 3d 74 79 70 65 3a 62 72 6f 61 64 63 9..a=type:broadc 0180 61 73 74 0d 0a 61 3d 63 6f 6e 74 72 6f 6c 3a 2a ast..a=control:* 0190 0d 0a 61 3d 73 6f 75 72 63 65 2d 66 69 6c 74 65 ..a=source-filte 01a0 72 3a 20 69 6e 63 6c 20 49 4e 20 49 50 34 20 2a r: incl IN IP4 * 01b0 20 31 39 32 2e 31 36 38 2e 31 30 2e 31 30 0d 0a 192.168.10.10.. 01c0 61 3d 72 74 63 70 2d 75 6e 69 63 61 73 74 3a 20 a=rtcp-unicast: 01d0 72 65 66 6c 65 63 74 69 6f 6e 0d 0a 61 3d 72 61 reflection..a=ra 01e0 6e 67 65 3a 6e 70 74 3d 30 2d 0d 0a 61 3d 78 2d nge:npt=0-..a=x- 01f0 71 74 2d 74 65 78 74 2d 6e 61 6d 3a 53 65 73 73 qt-text-nam:Sess 0200 69 6f 6e 20 73 74 72 65 61 6d 65 64 20 62 79 20 ion streamed by 0210 66 72 61 6e 6b 0d 0a 61 3d 78 2d 71 74 2d 74 65 frank..a=x-qt-te 0220 78 74 2d 69 6e 66 3a 66 72 61 6e 6b 0d 0a 6d 3d xt-inf:frank..m= 0230 76 69 64 65 6f 20 38 30 30 30 20 52 54 50 2f 41 video 8000 RTP/A 0240 56 50 20 39 36 0d 0a 63 3d 49 4e 20 49 50 34 20 VP 96..c=IN IP4 0250 31 39 32 2e 31 36 38 2e 31 30 2e 31 30 2f 32 35 192.168.10.10/25 0260 35 0d 0a 62 3d 41 53 3a 34 35 30 30 0d 0a 61 3d 5..b=AS:4500..a= 0270 72 74 70 6d 61 70 3a 39 36 20 48 32 36 34 2f 39 rtpmap:96 H264/9 0280 30 30 30 30 0d 0a 61 3d 66 6d 74 70 3a 39 36 20 0000..a=fmtp:96 0290 70 61 63 6b 65 74 69 7a 61 74 69 6f 6e 2d 6d 6f packetization-mo 02a0 64 65 3d 31 3b 70 72 6f 66 69 6c 65 2d 6c 65 76 de=1;profile-lev 02b0 65 6c 2d 69 64 3d 30 30 30 30 34 31 3b 73 70 72 el-id=000041;spr 02c0 6f 70 2d 70 61 72 61 6d 65 74 65 72 2d 73 65 74 op-parameter-set 02d0 73 3d 48 32 36 34 0d 0a 61 3d 63 6f 6e 74 72 6f s=H264..a=contro 02e0 6c 3a 74 72 61 63 6b 31 0d 0a l:track1.. ASCII bytes to tvb (3 bytes): 0000 00 00 41 ..A h264 prop-parameter-sets (3 bytes): 0000 1f 6e b8 .n. No. Time Source Destination Protocol Info 78 13.788745 192.168.10.4 192.168.10.10 RTSP SETUP rtsp://192.168.10.10:8554/testStream/track1 RTSP/1.0 Frame 78 (255 bytes on wire, 255 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) Transmission Control Protocol, Src Port: 36237 (36237), Dst Port: rtsp-alt (8554), Seq: 295, Ack: 831, Len: 187 Real Time Streaming Protocol Request: SETUP rtsp://192.168.10.10:8554/testStream/track1 RTSP/1.0\r\n Method: SETUP URL: rtsp://192.168.10.10:8554/testStream/track1 CSeq: 3\r\n Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: VLC media player (LIVE555 Streaming Media v2010.04.09)\r\n \r\n No. Time Source Destination Protocol Info 79 13.789426 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36237 [ACK] Seq=831 Ack=482 Win=9008 Len=0 TSV=1775866 TSER=29324856 80 13.837882 192.168.10.10 192.168.10.4 RTSP Reply: RTSP/1.0 461 Unsupported Transport Frame 80 (152 bytes on wire, 152 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.10 (192.168.10.10), Dst: 192.168.10.4 (192.168.10.4) Transmission Control Protocol, Src Port: rtsp-alt (8554), Dst Port: 36237 (36237), Seq: 831, Ack: 482, Len: 84 Real Time Streaming Protocol Response: RTSP/1.0 461 Unsupported Transport\r\n Status: 461 CSeq: 3\r\n Date: Thu, Jan 01 1970 02:32:59 GMT\r\n \r\n No. Time Source Destination Protocol Info 81 13.837898 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36237 [FIN, ACK] Seq=915 Ack=482 Win=9008 Len=0 TSV=1775876 TSER=29324856 82 13.838271 192.168.10.4 192.168.10.10 RTSP SETUP rtsp://192.168.10.10:8554/testStream/track1 RTSP/1.0 Frame 82 (257 bytes on wire, 257 bytes captured) Linux cooked capture Internet Protocol, Src: 192.168.10.4 (192.168.10.4), Dst: 192.168.10.10 (192.168.10.10) Transmission Control Protocol, Src Port: 36237 (36237), Dst Port: rtsp-alt (8554), Seq: 482, Ack: 916, Len: 189 Real Time Streaming Protocol Request: SETUP rtsp://192.168.10.10:8554/testStream/track1 RTSP/1.0\r\n Method: SETUP URL: rtsp://192.168.10.10:8554/testStream/track1 CSeq: 4\r\n Transport: RTP/AVP;unicast;client_port=8000-8001 User-Agent: VLC media player (LIVE555 Streaming Media v2010.04.09)\r\n \r\n No. Time Source Destination Protocol Info 83 13.838986 192.168.10.10 192.168.10.4 TCP rtsp-alt > 36237 [RST] Seq=916 Win=0 Len=0 84 13.839006 192.168.10.4 192.168.10.10 RTCP Receiver Report Goodbye -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 9 21:12:05 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Aug 2010 14:12:05 +1000 Subject: [Live-devel] Can RTCP control bitrate according to netwrok quality? In-Reply-To: <68D227E48F4B0F4EB6161523402601BE6CE747@PEKW987A.cn001.siemens.net> References: <68D227E48F4B0F4EB6161523402601BE6CE747@PEKW987A.cn001.siemens.net> Message-ID: > I have implemented a VOD based on live555 via unicast, now I >want to know how RTCP control bitrate according to network quality, >this means, if network is very bad between server and client, RTCP >can reduce bitrate automatically until network is becoming good. How >should I do? The IETF has done work in defining such a protocol (specifically, the RTP/AVPF profile, with some RTCP extensions), bue we don't currently implement these ourselves. Therefore, you would need to add such an implementation yourself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.toma at fundp.ac.be Thu Aug 12 06:25:24 2010 From: george.toma at fundp.ac.be (George Toma) Date: Thu, 12 Aug 2010 15:25:24 +0200 Subject: [Live-devel] Sending RTP packets in advance Message-ID: <4C63F644.6000607@fundp.ac.be> Hello, In a streaming session, we want to send a part of the streamed video in advance to the client. Is there a RTP packet scheduler in the Live555 media server that can be modified to do this? Or maybe, it could be possible to send during a certain period the video at a higher rate than the video frame rate. In which class should this be applied? We are using a slightly modified version of the Live555 server to send H264 packets. Thank you for your answer -- George Toma, Researcher --------------------------- Faculty of Computer Science University of Namur (FUNDP) http://www.fundp.ac.be/facultes/info/ Tel: +32 81 724 999 --------------------------- From benadroid at gmail.com Tue Aug 10 11:50:24 2010 From: benadroid at gmail.com (Ben L.) Date: Tue, 10 Aug 2010 11:50:24 -0700 Subject: [Live-devel] Live streaming source (mobile phone camera) Message-ID: Ben L. to live-devel show details 11:05 AM (37 minutes ago) Hi, I'm new to the group and video streaming. I followed the instruction from the link below to stream video from Android phone camera. I kind of understand how to implement pieces of it but not the whole thing to make it work. I wonder if anyone has implemented it using testOnDemandRTSPServer or something similar and can explain more detail of the changes or, even more helpful, share some sample codes of the changes? Thanks... http://www.live555.com/liveMedia/faq.html#liveInput-unicast ~BL On Sun, Aug 8, 2010 at 8:12 PM, wrote: > > > Message: 2 > Date: Tue, 3 Aug 2010 15:10:00 -0700 > From: Ross Finlayson > Subject: Re: [Live-devel] RTP over HTTP > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii"; Format="flowed" > > > >I have already read the various articles of comparisons of TCP vs > >UDP for RTP and I understand the differences. > > > >What I am looking for is > > > >a. Has anyone tried the LIVE555 code running it as a server > >successfully for RTP over HTTP > > Do you really mean "RTP over HTTP"? Our server implementation does > not (yet) support "RTP over HTTP". I think you mean "RTP over RTSP". > > > > for compressed live video (such as H.264 coming from a camera - not > >just playing off a disk and not just uncompresssed video) ? > > > >If so, > >b. What was your experience - did you notice any video quality > >issues - or any other difference from playing it over UDP ? > > > >c. Did you need to make any changes to the LIVE555 code to get this > >to work or did the existing code base work out of the box ? > > See -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgnurrahmat at gmail.com Wed Aug 11 03:13:29 2010 From: rgnurrahmat at gmail.com (RG Nur Rahmat) Date: Wed, 11 Aug 2010 17:13:29 +0700 Subject: [Live-devel] How to stream to Nokia's Real Player Message-ID: Hi, I've tried to stream video to Nokia's Real Player (S60) in LAN configuration by using VLC, it worked in LAN but it didn't work in Internet environment. And, I've tried VLC to stream video to another VLC in Internet environment, this also did not work, whereas, VLC uses Live555MediaServer, yet, I can view the video in VLC, so, what's the difference between Live555MediaServer and VLC? How does Live555 traverse NAT? Do you have some kind of in-built RTSP Proxy server? How does it work actually? Kind regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From arang1978 at gmail.com Thu Aug 12 02:58:01 2010 From: arang1978 at gmail.com (Aranganathan Sankaradoss) Date: Thu, 12 Aug 2010 18:58:01 +0900 Subject: [Live-devel] How to recover data after 30 seconds Message-ID: hello Friends, For implementing RTSP client, I integrated Live555 source code with my project. If the RTSP server's restarting time is over 30 seconds then the openRTSP could not be able to record the stream. Does any one know about how to wait for the data until the server gets restarted? Thank you in advance. Regards, Aranganathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pushkar at ipvideosys.com Tue Aug 17 08:24:29 2010 From: pushkar at ipvideosys.com (Pushkar Pradhan) Date: Tue, 17 Aug 2010 08:24:29 -0700 Subject: [Live-devel] How to detect packet loss Message-ID: <5358224A8253E24D8D8E7FA9244E5407B5BE65@ipvmail.ipvideosys.com> Hi, While running the liveMedia client to receive RTP packets I acquire some statistics on the streamed data. I can easily get the total number of packets received and the number of bytes received like this: pVideoSrc->RTPgs()->statsGroupIncoming.totNumPackets() pVideoSrc->RTPgs()->statsGroupIncoming.totNumBytes() (RTPSource *pVideoSrc = pSubSession->rtpSource();) I would also like to check if packet loss occurred. I don't see any public method or member that can give me this. There is just this private member variable fPacketLossInFragmentedFrame of MultiFramedRTPSouce. Is there any method I can use on the source to find number of packets lost so far? Thanks, pushkar -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 17 16:04:00 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Aug 2010 08:34:00 +0930 Subject: [Live-devel] How to detect packet loss In-Reply-To: <5358224A8253E24D8D8E7FA9244E5407B5BE65@ipvmail.ipvideosys.com> References: <5358224A8253E24D8D8E7FA9244E5407B5BE65@ipvmail.ipvideosys.com> Message-ID: >While running the liveMedia client to receive RTP packets I acquire >some statistics on the streamed data. I can easily get the total >number of packets received and the number of bytes received like >this: >pVideoSrc->RTPgs()->statsGroupIncoming.totNumPackets() >pVideoSrc->RTPgs()->statsGroupIncoming.totNumBytes() >(RTPSource *pVideoSrc = pSubSession->rtpSource();) > >I would also like to check if packet loss occurred. I don't see any >public method or member that can give me this. There is just this >private member variable fPacketLossInFragmentedFrame of >MultiFramedRTPSouce. > >Is there any method I can use on the source to find number of >packets lost so far? Yes. You can use the "RTPReceptionStats" class for this. For illustration, look at how the "openRTSP" client application implements the "-Q" option (see "testProgs/playCommon.cpp"). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 17 16:06:08 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Aug 2010 08:36:08 +0930 Subject: [Live-devel] How to stream to Nokia's Real Player In-Reply-To: References: Message-ID: >VLC uses Live555MediaServer No it doesn't. VLC uses a separate RTSP server implementation. VLC currently uses the "LIVE555 Streaming Media" code only for RTSP *client* operations. Questions about VLC - especially, using VLC as a server - should be sent to a VLC mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Aug 18 17:08:44 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Aug 2010 10:08:44 +1000 Subject: [Live-devel] Sending RTP packets in advance In-Reply-To: <4C63F644.6000607@fundp.ac.be> References: <4C63F644.6000607@fundp.ac.be> Message-ID: >In a streaming session, we want to send a part of the streamed video >in advance to the client. Is there a RTP packet scheduler in the >Live555 media server that can be modified to do this? >Or maybe, it could be possible to send during a certain period the >video at a higher rate than the video frame rate. In which class >should this be applied? Probably the best place to do this would be in the 'framer' object that feeds into your "RTPSink" (subclass) object. Specifically, you would calculate "fPresentationTime" exactly the same way as for normal streaming (because the presentation time represents the playback time for the receiving client). However, you could change the calculation of "fDurationInMicroseconds" to alter the rate at which frames (and thus network packets) are sent. You should not need to change any other parts of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tamj01 at hotmail.com Thu Aug 19 07:39:44 2010 From: tamj01 at hotmail.com (John Tam) Date: Thu, 19 Aug 2010 10:39:44 -0400 Subject: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client In-Reply-To: References: , Message-ID: Hello Ross, I have update to the latest July 29, 2010 version of LiveMedia. The same problem exists. Regards, John > Date: Sun, 8 Aug 2010 06:33:50 -0700 > To: live-devel at ns.live555.com > From: finlayson at live555.com > Subject: Re: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client > > >I have not updated myself to the latest, but I am only working on an > >older version of the LiveMedia library from March 16, 2010. > > Sorry, but no support is given for old versions of the code. There > have been significant changes to the code (including to RTP-over-TCP > handling) since then. > -- > > 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 snarayanan at a2etechnologies.com Thu Aug 19 14:10:40 2010 From: snarayanan at a2etechnologies.com (Shyam Narayanan) Date: Thu, 19 Aug 2010 14:10:40 -0700 Subject: [Live-devel] live.doxygen config file Message-ID: <1B9A9D002C346449A8A14D50C168C84F010C52D8@exchsrvr.A2E.local> Hi I am looking for the live.doxygen config file described here in this article. Does someone know where I can find it ? I couldnt find it in the Luca's tar.gz or the latest live source code. I have made changes to the code for my implementation and I would like my documentation to reflect those. When I run doxygen using the default config file it generates, the output is not as good as the doxygen document provided on your site. So starting off with the one that was used before would be extremely helpful. Shyam [Live-devel] doxygen doc for live Ross Finlayson finlayson at live.com Tue Apr 20 18:34:21 PDT 2004 * Previous message: [Live-devel] doxygen doc for live * Next message: [Live-devel] doxygen doc for live * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] At 05:05 PM 4/20/04, you wrote: >The generation of the doc is really simple, I've only generated a >doxygen configuration file (live.doxygen) and I've executed "doxygen >live.doxygen", with no changes to the existing source code. > >If you want, I can give you my configuration file. Luca, Yes, please send it to the list. I'll look into using this to generate doxygen content automatically, to be put on the LIVE.COM web site. Thanks again for taking the time to do this. This has been on my 'to do' list for a while, but I hadn't really had the time to look into it... Ross Finlayson LIVE.COM -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewpaus at pobox.com Thu Aug 19 16:39:46 2010 From: ewpaus at pobox.com (Estelle W. Paus) Date: Thu, 19 Aug 2010 19:39:46 -0400 Subject: [Live-devel] Decoding h264 from an RTSP stream Message-ID: <4C6DC0C2.8080008@pobox.com> Using your live555 libraries and ffmpeg, I am trying to write an h264 player that uses RTSP. Although I successfully seem to be receiving the RTP packets, they are not being decoded. In researching this problem I have noticed the following: ffmpeg h264 decoder seems to be looking for 001 When stepping through mplayer code, it finds this 001. When I look at the stream with Wireshark, I do not see a 001. My program that uses live555 and ffmpeg can't find 001 in the frame. Questions: Is the live555 library adding this 001 and if so where and how do I tell it to do it? Thank you so much. Estelle From ewpaus at pobox.com Thu Aug 19 16:41:44 2010 From: ewpaus at pobox.com (Estelle W. Paus) Date: Thu, 19 Aug 2010 19:41:44 -0400 Subject: [Live-devel] Using openRTSP to receive and decode h264 stream Message-ID: <4C6DC138.5060808@pobox.com> Hi, Regarding your FAQ entry, "Can I stream H.264 video via RTP? None of the test programs illustrate this." I have a couple of questions. I'm using your live555 library to receive RTSP. I have been using mplayer as a guide as suggested on the openRTSP page. I am also using the libavcodec decoder, but it doesn't work. I noticed in your FAQ you said that h264 could be used with your live555 library if you implement currentNALUnitEndsAccessUnit(). But I cannot find this function used anywhere in the mplayer source tree. At what point in initialization of live555 would you create H264VideoStreamFramer class that implements it? And to what do you give it? I've been working on this problem for 2 months now and I just keep hitting walls. I know it's been done. Do you have any insight that could help? I seem to be receiving packets. My problem starts with the decoder unable to decode any frames. Thank you, Estelle From pushkar at ipvideosys.com Fri Aug 20 09:01:41 2010 From: pushkar at ipvideosys.com (Pushkar Pradhan) Date: Fri, 20 Aug 2010 09:01:41 -0700 Subject: [Live-devel] Decoding h264 from an RTSP stream References: <4C6DC0C2.8080008@pobox.com> Message-ID: <5358224A8253E24D8D8E7FA9244E5407B5BE6C@ipvmail.ipvideosys.com> ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Estelle W. Paus Sent: Thu 8/19/2010 4:39 PM To: live-devel at ns.live555.com Subject: [Live-devel] Decoding h264 from an RTSP stream Using your live555 libraries and ffmpeg, I am trying to write an h264 player that uses RTSP. Although I successfully seem to be receiving the RTP packets, they are not being decoded. In researching this problem I have noticed the following: ffmpeg h264 decoder seems to be looking for 001 When stepping through mplayer code, it finds this 001. When I look at the stream with Wireshark, I do not see a 001. My program that uses live555 and ffmpeg can't find 001 in the frame. Questions: Is the live555 library adding this 001 and if so where and how do I tell it to do it? Hello Estelle, According to the RFC for H.264 RTP the RTP sender does not have to send the NALU start code prefix (0x000001). Neither does the RTP framing logic on the receiver have to insert this. This is done to save bandwidth. You can easily prefix the start code prefix to the NALU you receive in your sink implementation. You can look at the H264VideoFileSink implementation it must be doing the same, I used my own sink though. pushkar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4151 bytes Desc: not available URL: From pushkar at ipvideosys.com Fri Aug 20 09:06:13 2010 From: pushkar at ipvideosys.com (Pushkar Pradhan) Date: Fri, 20 Aug 2010 09:06:13 -0700 Subject: [Live-devel] gettimeofday windows implementation Message-ID: <5358224A8253E24D8D8E7FA9244E5407B5BE6D@ipvmail.ipvideosys.com> Hi, I would like to modify the gettimeofday implementation (provided for Windoze) in groupsockhelper.cpp to make it thread safe for my use. I was planning on using the old implementation which just calls ftime(&tb) to avoid the use of static variables. I noticed the comments for the routine that QueryPerformanceCounter is more accurate that's why you use it. My question is if I use ftime in each call what kind of side effects will it cause if any? Thanks, pushkar -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilya at darim.com Fri Aug 20 04:10:36 2010 From: ilya at darim.com (Ilya Smelykh) Date: Fri, 20 Aug 2010 18:10:36 +0700 Subject: [Live-devel] Decoding h264 from an RTSP stream In-Reply-To: <4C6DC0C2.8080008@pobox.com> References: <4C6DC0C2.8080008@pobox.com> Message-ID: Hi, Actually for regular H.264 RTP Payload all NALU sends without startcode 00000001. RTP source on client side should make defragmentation of vido frame and add prefix with starcode bytes. In my opinion you should use openRTSP program as start point and write you own h.264 decoder and render classes. Ilya Smelykh. 2010/8/20 Estelle W. Paus > Using your live555 libraries and ffmpeg, I am trying to write an h264 > player that uses RTSP. Although I successfully seem to be receiving > the RTP packets, they are not being decoded. In researching this problem I > have noticed the following: > > ffmpeg h264 decoder seems to be looking for 001 > > When stepping through mplayer code, it finds this 001. > When I look at the stream with Wireshark, I do not see a 001. > > My program that uses live555 and ffmpeg can't find 001 in the frame. > > Questions: > > Is the live555 library adding this 001 and if so where and how do I tell it > to do it? > > Thank you so much. > Estelle > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilya at darim.com Fri Aug 20 04:16:39 2010 From: ilya at darim.com (Ilya Smelykh) Date: Fri, 20 Aug 2010 18:16:39 +0700 Subject: [Live-devel] Using openRTSP to receive and decode h264 stream In-Reply-To: <4C6DC138.5060808@pobox.com> References: <4C6DC138.5060808@pobox.com> Message-ID: Your question was many times discussed on this maillist, just search the answer using google with query like this "h.264 rtp site:lists.live555.com" 2010/8/20 Estelle W. Paus > Hi, > > Regarding your FAQ entry, "Can I stream H.264 video via RTP? None of the > test programs illustrate this." I have a couple of questions. > > I'm using your live555 library to receive RTSP. I have been using mplayer > as a guide as suggested on the openRTSP page. I am also using the > libavcodec decoder, but it doesn't work. I noticed in your FAQ you said > that h264 could be used with your live555 library if you implement > currentNALUnitEndsAccessUnit(). But I cannot find this function used > anywhere in the mplayer source tree. At what point in initialization of > live555 would you create H264VideoStreamFramer class that implements it? > And to what do you give it? > > I've been working on this problem for 2 months now and I just keep hitting > walls. I know it's been done. Do you have any insight that could help? > > I seem to be receiving packets. My problem starts with the decoder unable > to decode any frames. > Thank you, > Estelle > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilya at darim.com Fri Aug 20 10:39:29 2010 From: ilya at darim.com (Ilya Smelykh) Date: Sat, 21 Aug 2010 00:39:29 +0700 Subject: [Live-devel] MP2TS Message-ID: I just write app based on live555 lib which mux h.264 raw stream to MP2TS, my stream source is hw encoder which gives me h.264 slices. My problem is PTS estimation algorithm in MPEG2TransportStreamMuxer, I found that when the I frame has big difference from P frame so the frame duration time estimation algorithm gives problem with VLC player and many brand dshow filters skip frames and the video is jerking. Even I set pts from hw encoder chip, the clients video is jerking. The jerking is appears when the I frame is coming, cuz its this is too much more than P frame(for ex. : P frame is 10Kb and I frame is 100Kb). Can some one give an advice what to do with that problem. Thank you and Best Regards. Ilya Smelykh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deets at web.de Fri Aug 20 12:08:57 2010 From: deets at web.de (Diez B. Roggisch) Date: Fri, 20 Aug 2010 21:08:57 +0200 Subject: [Live-devel] displaying RTSP stream directly Message-ID: <58E28854-59FE-4145-834D-9C2D57D2E7A1@web.de> Hi all, this is most probably a stupid question, but I've been banging my head on this for several days now, to no avail so far. My general scenario is this: - grab an MP4V-ES/90000 stream from a FLIR Infrared Camera (the camera works, grabbing RTSP from it using VLC has no problems) - decode the data - display it together with additional information All this takes place under OSX. Now what I have so far is this: - A python twisted based RTSP-client which gets RTP-frames from the camera. The concatenation of these leads to a file which the "file"- command describes as /tmp/camera.output: MPEG sequence, v4, video, simple @ L3 - Pretty much the same program, modeled after openRTSP, in ObjectiveC/Cocoa/C++ using live555 (thus I ask here) which produces the same data-stream. This data is unfortunately *not* decodable by VLC (which I want to use for testing only anyway). But what I'm really after is to decode the data to get the raw pixels, then show these inside a NSView. Now I'm totally lost here. In my dream-world, I'd be feeding the returned data to a MP4-decoder, which in turn yields a raw image file every now and then. Apparently, things aren't that easy. I've scratched my head looking at QuickTimeFileSink, but I guess much of it's > 2K lines of complexity comes from producing a QuickTime-mov- container file or some such. If I absolutely *have* to use that, I'm somehow using that. But of course I want this to be piped/filtered, *not* dumped on the drive & then read again. Any suggestions? Thanks, Diez From jens.binder at hhi.fraunhofer.de Fri Aug 20 04:27:37 2010 From: jens.binder at hhi.fraunhofer.de (Jens Binder) Date: Fri, 20 Aug 2010 13:27:37 +0200 Subject: [Live-devel] Decoding h264 from an RTSP stream In-Reply-To: <4C6DC0C2.8080008@pobox.com> References: <4C6DC0C2.8080008@pobox.com> Message-ID: Hej Estelle > Using your live555 libraries and ffmpeg, I am trying to write an h264 > player that uses RTSP. Although I successfully seem to be receiving > the RTP packets, they are not being decoded. In researching this problem > I have noticed the following: > > ffmpeg h264 decoder seems to be looking for 001 0x000001 is the start code for any H.264 NAL unit! > > When stepping through mplayer code, it finds this 001. > When I look at the stream with Wireshark, I do not see a 001. > The start units are not transmitted via RTP. The marker bit indicates, that a NAL-unit is finished - then your client has to add the start code to the currently received frame > My program that uses live555 and ffmpeg can't find 001 in the frame. > > Questions: > > Is the live555 library adding this 001 and if so where and how do I tell > it to do it? afterGettingFrame1() function in your Client - most probably a subclass of MediaSink take a deeper look into RFC3984 for H.264 over RTP and the H.264 specification itself which answers most of you questions: http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-201003-I!!PDF-E&type=items jens. From jens.binder at hhi.fraunhofer.de Fri Aug 20 05:04:09 2010 From: jens.binder at hhi.fraunhofer.de (Jens Binder) Date: Fri, 20 Aug 2010 14:04:09 +0200 Subject: [Live-devel] Using openRTSP to receive and decode h264 stream In-Reply-To: <4C6DC138.5060808@pobox.com> References: <4C6DC138.5060808@pobox.com> Message-ID: Hi, > Hi, > > Regarding your FAQ entry, "Can I stream H.264 video via RTP? None of the > test programs illustrate this." I have a couple of questions. > This FAQ-entry is only for *streaming* - which means sending out H.264 frames via RTP/RTSP > I'm using your live555 library to receive RTSP. I have been using > mplayer as a guide as suggested on the openRTSP page. From your question I suppose you want to *receive* data! > I am also using > the libavcodec decoder, but it doesn't work. I noticed in your FAQ you > said that h264 could be used with your live555 library if you implement > currentNALUnitEndsAccessUnit(). But I cannot find this function used > anywhere in the mplayer source tree. At what point in initialization of > live555 would you create H264VideoStreamFramer class that implements it? > And to what do you give it? The H264VideoStreamFramer is only used for streaming (sending) H264 data - not for receiving data. You don't need it at all. > > I've been working on this problem for 2 months now and I just keep > hitting walls. I know it's been done. Do you have any insight that could > help? use the doxygen together with the test-programs for understanding the code - it's not straight-forward but works perfectly once you understand what is happening!! The basic steps in receiving RTSP-data are: 1. use RTSPClient for getting a SDP from the server 2. use SDP-description for creating a MediaSession 3. initiate the MediaSubsessions of the MediaSession 4. call RTSPClient::setupMediaSubsession for every Subsession 5. build and add a MediaSink to the Subsessions (mostly a subclass of MediaSink where you define what to do with the received data) 6. start the stream by calling MediaSink::startPlaying, RTSP::playMediaSession and finally starting the eventLoop. this is roughly what is done by openRTSP. Have a close look on both openRTSP.cpp and playCommon.cpp where mainly everything is done what you are requesting. Hope I could help you, Jens. From finlayson at live555.com Fri Aug 20 17:24:14 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Aug 2010 10:24:14 +1000 Subject: [Live-devel] Decoding h264 from an RTSP stream In-Reply-To: <4C6DC0C2.8080008@pobox.com> References: <4C6DC0C2.8080008@pobox.com> Message-ID: As others have noted, the NAL units - when sent within RTP packets - do *not* contain the initial 0x00000001 code. Also, our "H264VideoRTPSource" class - which delivers NAL units (one-at-a-time) from a RTP stream - does not insert this code. Therefore, if a decoder requires this code, you must add it yourself, in whatever class (that you write) receives data from the "H264VideoRTPSource". Note, BTW, that the "H264VideoFileSink" class - which "openRTSP" uses when it receives a H.264 RTSP/RTP stream - *does* insert this code. So, you might choose to use the "H264VideoFileSink" class if you want to write the received H.264 data to a file (or to "stdout", if you want to pipe it to a decoder). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ewpaus at pobox.com Fri Aug 20 17:36:44 2010 From: ewpaus at pobox.com (Estelle W. Paus) Date: Fri, 20 Aug 2010 20:36:44 -0400 Subject: [Live-devel] Decoding h264 from an RTSP stream Message-ID: <4C6F1F9C.9080201@pobox.com> Pushkar, Thank you so much for your reply. I've identified the code you're talking about in H264VideoFileSink, but at what point in the processing is this done. I was using mplayer as a guide to what needs to be done. But, mplayer doesn't use any of those Livee555 classes like H264VideoFileSink. So, I'm having problems figureing out how it all fits together. Using live555 classes I've sort of traced what's going on through getting a MediaSession. Then it all falls apart. I don't know where Sink fits in, though I suspect it's sometime before decoding starts. Could you fill in some of the high level (pseudo code) steps between initializing subsessions and rtpCodecInitialize_video? Does what I'm writing even make sense? Oh dear. Thanks, Estelle From: live-devel-bounces at ns.live555.com on behalf of Estelle W. Paus Sent: Thu 8/19/2010 4:39 PM To: live-devel at ns.live555.com Subject: [Live-devel] Decoding h264 from an RTSP stream Using your live555 libraries and ffmpeg, I am trying to write an h264 player that uses RTSP. Although I successfully seem to be receiving the RTP packets, they are not being decoded. In researching this problem I have noticed the following: ffmpeg h264 decoder seems to be looking for 001 When stepping through mplayer code, it finds this 001. When I look at the stream with Wireshark, I do not see a 001. My program that uses live555 and ffmpeg can't find 001 in the frame. Questions: Is the live555 library adding this 001 and if so where and how do I tell it to do it? Hello Estelle, According to the RFC for H.264 RTP the RTP sender does not have to send the NALU start code prefix (0x000001). Neither does the RTP framing logic on the receiver have to insert this. This is done to save bandwidth. You can easily prefix the start code prefix to the NALU you receive in your sink implementation. You can look at the H264VideoFileSink implementation it must be doing the same, I used my own sink though. pushkar From finlayson at live555.com Fri Aug 20 18:03:49 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Aug 2010 11:03:49 +1000 Subject: [Live-devel] displaying RTSP stream directly In-Reply-To: <58E28854-59FE-4145-834D-9C2D57D2E7A1@web.de> References: <58E28854-59FE-4145-834D-9C2D57D2E7A1@web.de> Message-ID: > - grab an MP4V-ES/90000 stream from a FLIR Infrared Camera (the >camera works, grabbing RTSP from it using VLC has no problems) [...] > - Pretty much the same program, modeled after openRTSP, in >ObjectiveC/Cocoa/C++ using live555 (thus I ask here) which produces >the same data-stream. > >This data is unfortunately *not* decodable by VLC VLC can't always correctly identify an arbitrary data file, which (partly) explains why it often can correctly display a stream from a "rtsp://" URL, but cannot play it from a data file (e.g., one that's recorded by "openRTSP"). In any case, this is not a VLC mailing list; problems with VLC should be reported on some other mailing list. However, in this case, it's possible that the MPEG-4 stream contains extra 'config' information (present in the stream's SDP description) that would need to be decoded and then prepended to the data stream that is passed to the your decoder. You can check this by looking for a "config=" string in the stream's SDP description (as reported by "openRTSP"). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Aug 20 18:10:30 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Aug 2010 11:10:30 +1000 Subject: [Live-devel] gettimeofday windows implementation In-Reply-To: <5358224A8253E24D8D8E7FA9244E5407B5BE6D@ipvmail.ipvideosys.com> References: <5358224A8253E24D8D8E7FA9244E5407B5BE6D@ipvmail.ipvideosys.com> Message-ID: >I would like to modify the gettimeofday implementation (provided for >Windoze) in groupsockhelper.cpp to make it thread safe for my use. I hope you have read the FAQ entry about threads. >I noticed the comments for the routine that QueryPerformanceCounter >is more accurate that's why you use it. My question is if I use >ftime in each call what kind of side effects will it cause if any? It will likely cause your application to perform badly, because timed events will happen at too coarse a granularity. I don't recommend changing the current implementation. If you really want to make it accessible by multiple threads (for whatever reason), then I suggest placing locks around the implementation, or else writing a new version (with a different name) that could you use just from your non-LIVE555 threads. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 20 18:41:38 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Aug 2010 11:41:38 +1000 Subject: [Live-devel] live.doxygen config file In-Reply-To: <1B9A9D002C346449A8A14D50C168C84F010C52D8@exchsrvr.A2E.local> References: <1B9A9D002C346449A8A14D50C168C84F010C52D8@exchsrvr.A2E.local> Message-ID: (Note that the message you referred to was more than *6 years old*!) We already run "Doxygen" for you, so you don't need to run it yourself. You can access the documentation for the "LIVE555 Streaming Media" code at http://www.live555.com/liveMedia/doxygen/html/ -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From pushkar at ipvideosys.com Sat Aug 21 12:23:14 2010 From: pushkar at ipvideosys.com (Pushkar Pradhan) Date: Sat, 21 Aug 2010 12:23:14 -0700 Subject: [Live-devel] gettimeofday windows implementation References: <5358224A8253E24D8D8E7FA9244E5407B5BE6D@ipvmail.ipvideosys.com> Message-ID: <5358224A8253E24D8D8E7FA9244E5407B5BE70@ipvmail.ipvideosys.com> ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Fri 8/20/2010 6:10 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] gettimeofday windows implementation I would like to modify the gettimeofday implementation (provided for Windoze) in groupsockhelper.cpp to make it thread safe for my use. I hope you have read the FAQ entry about threads. Yes, that's why I only want to do it for my own version :-) I noticed the comments for the routine that QueryPerformanceCounter is more accurate that's why you use it. My question is if I use ftime in each call what kind of side effects will it cause if any? It will likely cause your application to perform badly, because timed events will happen at too coarse a granularity. Ok, that answers my concern. I don't recommend changing the current implementation. If you really want to make it accessible by multiple threads (for whatever reason), then I suggest placing locks around the implementation, or else writing a new version (with a different name) that could you use just from your non-LIVE555 threads. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ pushkar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4709 bytes Desc: not available URL: From pushkar at ipvideosys.com Sat Aug 21 12:33:35 2010 From: pushkar at ipvideosys.com (Pushkar Pradhan) Date: Sat, 21 Aug 2010 12:33:35 -0700 Subject: [Live-devel] Decoding h264 from an RTSP stream References: <4C6F1F9C.9080201@pobox.com> Message-ID: <5358224A8253E24D8D8E7FA9244E5407B5BE71@ipvmail.ipvideosys.com> ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Estelle W. Paus Sent: Fri 8/20/2010 5:36 PM To: live-devel at ns.live555.com Subject: [Live-devel] Decoding h264 from an RTSP stream Pushkar, Thank you so much for your reply. I've identified the code you're talking about in H264VideoFileSink, but at what point in the processing is this done. I was using mplayer as a guide to what needs to be done. But, mplayer doesn't use any of those Livee555 classes like H264VideoFileSink. So, I'm having problems figureing out how it all fits together. Using live555 classes I've sort of traced what's going on through getting a MediaSession. Then it all falls apart. I don't know where Sink fits in, though I suspect it's sometime before decoding starts. Could you fill in some of the high level (pseudo code) steps between initializing subsessions and rtpCodecInitialize_video? Does what I'm writing even make sense? Oh dear. Thanks, Estelle Estelle, This processing is done when you receive the complete frame/NALU. Please compile and follow the openRTSP program to understand how RTP packets are processed in livemedia stack. Basically on the receiver side the liveMedia stack assembles complete frames/(NALUs in case of H.264) from the RTP data and delivers it to you in your sink. Here you can do whatever you want with it like record it to a file or decode it. I also suggest you read the liveMedia online documentation and FAQ. You need to understand the concept of sources and sinks. It has a good explanation of how data flows in the stack. pushkar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4379 bytes Desc: not available URL: From deets at web.de Sun Aug 22 04:00:50 2010 From: deets at web.de (Diez B. Roggisch) Date: Sun, 22 Aug 2010 13:00:50 +0200 Subject: [Live-devel] displaying RTSP stream directly In-Reply-To: References: <58E28854-59FE-4145-834D-9C2D57D2E7A1@web.de> Message-ID: Hi Ross, thanks for the answer. See below for some comments. >> - grab an MP4V-ES/90000 stream from a FLIR Infrared Camera (the >> camera works, grabbing RTSP from it using VLC has no problems) > > [...] > >> - Pretty much the same program, modeled after openRTSP, in >> ObjectiveC/Cocoa/C++ using live555 (thus I ask here) which produces >> the same data-stream. >> >> This data is unfortunately *not* decodable by VLC > > VLC can't always correctly identify an arbitrary data file, which > (partly) explains why it often can correctly display a stream from a > "rtsp://" URL, but cannot play it from a data file (e.g., one that's > recorded by "openRTSP"). In any case, this is not a VLC mailing > list; problems with VLC should be reported on some other mailing list. Well, yes and no. Maybe I'm not making myself clear here: I just mentioned VLC because it is obviously capable of what I hope to be able to do: - receiving RDP-packets which contain an MPEG-4-stream (I can do that using live555) - decoding it, so I have a bunch of pixels (... my missing step) - displaying them. (profit!) I'm aware that this is no strict live555 question. But I thought that you guys certainly don't "only" transmit stuff, but evenutally want it to display - so I thought you might have a suggestion for me how to hook e.g. a libavcodec mpeg4 decoder into a custom sink which will give me my raw image data. > > However, in this case, it's possible that the MPEG-4 stream contains > extra 'config' information (present in the stream's SDP description) > that would need to be decoded and then prepended to the data stream > that is passed to the your decoder. You can check this by looking > for a "config=" string in the stream's SDP description (as reported > by "openRTSP"). This is the SDP descroptor. I don't see config sections though. v=0 o=- 0 0 IN IP4 192.168.10.2 s=IR stream i=Live infrared t=now- c=IN IP4 192.168.10.2 m=video 10036 RTP/AVP 96 97 98 99 100 102 103 a=control:rtsp://192.168.10.2/sid=96 a=framerate:30 a=rtpmap:96 MP4V-ES/90000 a=framesize:96 640-480 a=fmtp:96 profile-level- id=1;config=000001B005000001B509000001010000012002045D4C28A021E0A4C7 a=rtpmap:97 MP4V-ES/90000 a=framesize:97 320-240 a=fmtp:97 profile-level- id=1;config=000001B005000001B509000001010000012002045D4C285020F0A4C7 a=rtpmap:98 MP4V-ES/90000 a=framesize:98 160-128 a=fmtp:98 profile-level- id=1;config=000001B005000001B509000001010000012002045D4C285020F0A4C7 a=rtpmap:99 FCAM/90000 a=framesize:99 320-240 a=fmtp:99 sampling=mono; width=320; height=240; depth=16 a=rtpmap:100 FCAM/90000 a=framesize:100 160-120 a=fmtp:100 sampling=mono; width=160; height=120; depth=16 a=rtpmap:102 raw/90000 a=framesize:102 320-240 a=fmtp:102 sampling=mono; width=320; height=240; depth=16 a=rtpmap:103 raw/90000 a=framesize:103 160-120 Thanks, Diez From arang1978 at gmail.com Sun Aug 22 20:31:02 2010 From: arang1978 at gmail.com (Aranganathan Sankaradoss) Date: Mon, 23 Aug 2010 12:31:02 +0900 Subject: [Live-devel] how to avoid exiting from openRTSP Message-ID: Hello Sir, I am using openRTSP in my Set top box. I have 2 doubts. 1. Even though the RTSP server is stopped, I should not exit from RTSP client, I must keep on checking for the RTSP server connection. If the RTSP server is started then I should resume getting the data. 2. Without recording the stream, how to receive the stream in openRTSP and transfer the data to the demux in my Set top box? I know -r option, do not record the data, in this option, but if I use this option, is there any way to receive the data in a buffer? Regards, Aranganathan.S -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Aug 22 19:59:01 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Aug 2010 19:59:01 -0700 Subject: [Live-devel] displaying RTSP stream directly In-Reply-To: References: <58E28854-59FE-4145-834D-9C2D57D2E7A1@web.de> Message-ID: >>However, in this case, it's possible that the MPEG-4 stream >>contains extra 'config' information (present in the stream's SDP >>description) that would need to be decoded and then prepended to >>the data stream that is passed to the your decoder. You can check >>this by looking for a "config=" string in the stream's SDP >>description (as reported by "openRTSP"). > >This is the SDP descroptor. I don't see config sections though. Yes, it's there: The "config=" strings in the "a=fmtp:" lines. However, there's another problem with that stream: It specifies multiple possible payload format codes on the "m=video" line. That's perfectly legal, but unfortunately the "LIVE555 Streaming Media" code currently won't be able to receive it (unless the stream uses payload format code 96 only). Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From deets at web.de Mon Aug 23 03:01:05 2010 From: deets at web.de (Diez B. Roggisch) Date: Mon, 23 Aug 2010 12:01:05 +0200 Subject: [Live-devel] displaying RTSP stream directly In-Reply-To: References: <58E28854-59FE-4145-834D-9C2D57D2E7A1@web.de> Message-ID: <201008231201.05802.deets@web.de> On Monday, August 23, 2010 04:59:01 Ross Finlayson wrote: > >>However, in this case, it's possible that the MPEG-4 stream > >>contains extra 'config' information (present in the stream's SDP > >>description) that would need to be decoded and then prepended to > >>the data stream that is passed to the your decoder. You can check > >>this by looking for a "config=" string in the stream's SDP > >>description (as reported by "openRTSP"). > > > >This is the SDP descroptor. I don't see config sections though. > > Yes, it's there: The "config=" strings in the "a=fmtp:" lines. Ah. I thought they needed to be on the beginning. And of course the whole thing is rather opaque. > > However, there's another problem with that stream: It specifies > multiple possible payload format codes on the "m=video" line. That's > perfectly legal, but unfortunately the "LIVE555 Streaming Media" code > currently won't be able to receive it (unless the stream uses payload > format code 96 only). Sorry. Yep, but I'm actually only interested on the first one, and it works receiving that, and I at least once created a QT movie out of it. Albeit I didn't make that happen yesterday. But VLC also uses live555, and they work with this camera. However, I now pursue embedding VLC through VLCKit. Which has it's own perks, but looks most promising for now. Thanks for you help, and of course for the library as whole - even if I'll becoming an indirect user in the future :) Diez From snipefoo at free.fr Mon Aug 23 04:58:06 2010 From: snipefoo at free.fr (snipefoo at free.fr) Date: Mon, 23 Aug 2010 13:58:06 +0200 Subject: [Live-devel] From UDP Raw to RTSP Message-ID: <1282564686.4c72624eab6b4@webmail.free.fr> Hi, I need to stream in RTSP a media received by UDP Raw. I receive IPTV via multicast UDP (MPEG2 and h264) but I need a RTSP source to allow softwares like Eye TV to play IPTV. For those who know Freebox: I try to emulate a Freebox. I tried VLC and get some interesting results (using VLM) but now, I need to embed this solution into a router (running DD-WRT); VLC is not a good choice as it needs to many resources to run. So I think about writing a simple program doing only one thing : receive an UDP Raw stream and send it back as RTSP. I need to stream multiple channels, eg: rtsp://mybox/Channel_1 = udp://225.1.1.1 rtsp://mybox/Channel_2 = udp://225.1.1.2 ... As many demo progs nearly do what I need, I think it would not be too complicated to do that with LIVE555 Streaming Media library. But do you think it won't need too much cpu and/or memory to run on light hardware. I don't know what it represent to convert Raw UDP into RTP; is it the same format ? What is the best way to implement the multiple channels (is there such a mechanism in the library) ? Have you some advices for me ? Thank a lot. Best Regards Snipe Foo From ilya at darim.com Mon Aug 23 12:34:15 2010 From: ilya at darim.com (Ilya Smelykh) Date: Tue, 24 Aug 2010 02:34:15 +0700 Subject: [Live-devel] From UDP Raw to RTSP In-Reply-To: <1282564686.4c72624eab6b4@webmail.free.fr> References: <1282564686.4c72624eab6b4@webmail.free.fr> Message-ID: Do you really need RTP/RTSP? I think the best way for you is to save stream as you receive it and just add VoD part(RTSPServer) in retransmitter. live555 support RAW UDP with MP2TS + RTSP streaming. Only one thing is what you want to use as end side client and wether it support that kind of streaming. 2010/8/23 > Hi, > > I need to stream in RTSP a media received by UDP Raw. I receive IPTV via > multicast UDP (MPEG2 and h264) but I need a RTSP source to allow softwares > like > Eye TV to play IPTV. For those who know Freebox: I try to emulate a > Freebox. > > I tried VLC and get some interesting results (using VLM) but now, I need to > embed this solution into a router (running DD-WRT); VLC is not a good > choice as > it needs to many resources to run. > > So I think about writing a simple program doing only one thing : receive an > UDP > Raw stream and send it back as RTSP. > > I need to stream multiple channels, eg: > rtsp://mybox/Channel_1 = udp://225.1.1.1 > rtsp://mybox/Channel_2 = udp://225.1.1.2 > ... > > As many demo progs nearly do what I need, I think it would not be too > complicated to do that with LIVE555 Streaming Media library. But do you > think it > won't need too much cpu and/or memory to run on light hardware. I don't > know > what it represent to convert Raw UDP into RTP; is it the same format ? What > is > the best way to implement the multiple channels (is there such a mechanism > in > the library) ? > > Have you some advices for me ? > > Thank a lot. > Best Regards > Snipe Foo > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 23 18:38:00 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Aug 2010 18:38:00 -0700 Subject: [Live-devel] From UDP Raw to RTSP In-Reply-To: <1282564686.4c72624eab6b4@webmail.free.fr> References: <1282564686.4c72624eab6b4@webmail.free.fr> Message-ID: See http://www.live555.com/liveMedia/faq.html#liveInput-unicast (Remember, you were asked to read the FAQ before posting to the mailing list.) Also, you could use the class "BasicUDPSource" for your input. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From holylts at 163.com Wed Aug 25 02:34:33 2010 From: holylts at 163.com (holylts) Date: Wed, 25 Aug 2010 17:34:33 +0800 Subject: [Live-devel] a bug of "RTSPServer::addServerMediaSession" Message-ID: <201008251734317656823@163.com> live-devel,??? if (serverMediaSession == NULL) return; char const* sessionName = serverMediaSession->streamName(); if (sessionName == NULL) sessionName = ""; ServerMediaSession* existingSession = (ServerMediaSession*) (fServerMediaSessions->Add(sessionName, (void*)serverMediaSession)); removeServerMediaSession(existingSession); // if any?may be delete this codes? 2010-08-25 ?????????????? ????? holylts ???025-84707606-8034 ???15951936082 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 26 01:00:51 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Aug 2010 01:00:51 -0700 Subject: [Live-devel] a bug of "RTSPServer::addServerMediaSession" In-Reply-To: <201008251734317656823@163.com> References: <201008251734317656823@163.com> Message-ID: > >removeServerMediaSession(existingSession); // if any?ymay >be delete this codes?z No, this is not a bug, and you should not delete that line (from the implementation of "RTSPServer:: addServerMediaSession()"). If you happen to add a new "ServerMediaSession" object with a name that matches that of an existing "ServerMediaSession" object, then the existing object will no longer be accessible, and should therefore be removed from the server (so that it will get deleted automatically when clients are no longer using it). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cifrzak at gmail.com Sat Aug 28 05:15:17 2010 From: cifrzak at gmail.com (Cifrzak Gmail) Date: Sat, 28 Aug 2010 13:15:17 +0100 Subject: [Live-devel] JPEG multicast relay Message-ID: <4C78FDD5.6070201@gmail.com> Hi all, I have a situation where I have a relay host connected to two networks. On one there are cameras streaming JPEG frames via multicast (they use PassiveServerMediaSubsesson and JPEGVideoRTPSink with custom source class), on the other I have the clients which need to receive those streams. I'm not allowed to setup routing between the two networks. I was planning to run a relay between the two networks, which would receive the multicast streams and make them available on the client-side network, but with no success. My camera streamers do work (tested with VLC on their network), I can also receive data to a file on the relay. I can't re-stream it on the relay. The relay call flow is this: request stream information from camera via RTSP (works) retrieve FramedSource from the camera stream subsession (works) create rtp and rtcp groupsocks for streaming (works) create JPEGVideoRTPSink with above rtp groupsock (works) create RTCPInstance with the sink (works) create PassiveServerMediaSubsession using the sink and add it to relay RTSP send play command (works) sink->startPlaying() using the FramedSource I can't receive the stream streamed by relay host. RTSP commands are being exchanged but no data comes out afterwards. So the working vs non-working case is the relay can save to a file, but can't re-stream As you can see I have only vague knowledge about live555/streaming. Any help on the JPEG multicast relay is much appreciated. Many thanks From sebastien-devel at celeos.eu Mon Aug 30 03:40:54 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Mon, 30 Aug 2010 12:40:54 +0200 Subject: [Live-devel] bug when clock is reset back in time Message-ID: <1283164854.6072.19.camel@sebastien-desktop> Hi, Some time ago, I pointed out a bug when the clock is reset back in time, the cpu usage is 100% For reference, it's here : http://www.mail-archive.com/live-devel at lists.live555.com/msg04231.html Changelog says you fixed the bug in 2009.09.04, but I don't remember if I tested it or not. But when I test the latest release, the bug is still here. Step to reproduce : ./openRtsp rtsp://somestream change your system clock back in time. By the way, here again, a version control system would be very useful to find if the bug came back, how, and when... Best regards, Sebastien. From finlayson at live555.com Mon Aug 30 06:11:29 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Aug 2010 06:11:29 -0700 Subject: [Live-devel] bug when clock is reset back in time In-Reply-To: <1283164854.6072.19.camel@sebastien-desktop> References: <1283164854.6072.19.camel@sebastien-desktop> Message-ID: >Some time ago, I pointed out a bug when the clock is reset back in time, >the cpu usage is 100% >For reference, it's here : >http://www.mail-archive.com/live-devel at lists.live555.com/msg04231.html > >Changelog says you fixed the bug in 2009.09.04, but I don't remember if >I tested it or not. The problem you reported back then - setting the system clock backwards caused 100% CPU usage - was fixed in that release. >But when I test the latest release, the bug is still here. > >Step to reproduce : >./openRtsp rtsp://somestream >change your system clock back in time. The symptoms now are different: Instead of 100% CPU usage, "openRTSP" now stops recording data. I'll take another look at this, but this is low-priority... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sebastien-devel at celeos.eu Mon Aug 30 02:29:34 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Mon, 30 Aug 2010 11:29:34 +0200 Subject: [Live-devel] bug when clock is reset back in time In-Reply-To: References: <1283164854.6072.19.camel@sebastien-desktop> Message-ID: <1283160574.6072.23.camel@sebastien-desktop> On Mon, 2010-08-30 at 06:11 -0700, Ross Finlayson wrote: > The symptoms now are different: Instead of 100% CPU usage, "openRTSP" > now stops recording data. > No, I still have the 100% CPU usage... (see my top output) I tested some release I have on my computer (v2009.09.28, v2010.03.16, v2010.08.22) and I have this bug with all of them. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20764 sebastie 20 0 3352 1132 968 R 100 0.0 0:14.42 openRTSP From sagi at netvision.net.il Mon Aug 30 10:00:41 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Mon, 30 Aug 2010 20:00:41 +0300 Subject: [Live-devel] Getting the FPS at the client side Message-ID: <007c01cb4864$e0e514b0$a2af3e10$@net.il> Hi Ross, At the client streamer, when I get a video link (Mpeg4 or H264) I get a set of parameters but the subsession->videoFPS() (frames per second) is set to zero. How can I get the Fps of the video link? We use Live555 as our server to stream from real video source (h264 or mpeg4). Maybe we should set something at the server side? Thanks, Sagi -------------- next part -------------- An HTML attachment was scrubbed... URL: From pushkar at ipvideosys.com Mon Aug 30 11:04:08 2010 From: pushkar at ipvideosys.com (Pushkar Pradhan) Date: Mon, 30 Aug 2010 11:04:08 -0700 Subject: [Live-devel] Getting the FPS at the client side References: <007c01cb4864$e0e514b0$a2af3e10$@net.il> Message-ID: <5358224A8253E24D8D8E7FA9244E5407B5BE86@ipvmail.ipvideosys.com> ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Sagi Ben Moshe Sent: Mon 8/30/2010 10:00 AM To: live-devel at ns.live555.com Subject: [Live-devel] Getting the FPS at the client side Hi Ross, At the client streamer, when I get a video link (Mpeg4 or H264) I get a set of parameters but the subsession->videoFPS() (frames per second) is set to zero. How can I get the Fps of the video link? We use Live555 as our server to stream from real video source (h264 or mpeg4). Maybe we should set something at the server side? Thanks, Sagi Hi Sagi, I don't think you can always get the FPS from the SDP, i.e. it is not mandatory to set the fps in the sdp. For some codecs this info might be available in the bitstream itself. What do you plan to do with the FPS? By the way you can always estimate it in your sink. pushkar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4756 bytes Desc: not available URL: From sagi at netvision.net.il Mon Aug 30 11:45:12 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Mon, 30 Aug 2010 21:45:12 +0300 Subject: [Live-devel] Getting the FPS at the client side In-Reply-To: <5358224A8253E24D8D8E7FA9244E5407B5BE86@ipvmail.ipvideosys.com> References: <007c01cb4864$e0e514b0$a2af3e10$@net.il> <5358224A8253E24D8D8E7FA9244E5407B5BE86@ipvmail.ipvideosys.com> Message-ID: <008b01cb4873$7ac375a0$704a60e0$@net.il> Hi Pushkar, I would like to know if the stream is NTFS or PAL, we can do it by the size but we prefer to do it by the FPS. As I was written, we are also writing the server part using Live555 so just let me know where should I add it inside the server. Thanks, Sagi From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Pushkar Pradhan Sent: Monday, August 30, 2010 9:04 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Getting the FPS at the client side _____ From: live-devel-bounces at ns.live555.com on behalf of Sagi Ben Moshe Sent: Mon 8/30/2010 10:00 AM To: live-devel at ns.live555.com Subject: [Live-devel] Getting the FPS at the client side Hi Ross, At the client streamer, when I get a video link (Mpeg4 or H264) I get a set of parameters but the subsession->videoFPS() (frames per second) is set to zero. How can I get the Fps of the video link? We use Live555 as our server to stream from real video source (h264 or mpeg4). Maybe we should set something at the server side? Thanks, Sagi Hi Sagi, I don't think you can always get the FPS from the SDP, i.e. it is not mandatory to set the fps in the sdp. For some codecs this info might be available in the bitstream itself. What do you plan to do with the FPS? By the way you can always estimate it in your sink. pushkar -------------- next part -------------- An HTML attachment was scrubbed... URL: From pushkar at ipvideosys.com Mon Aug 30 13:31:44 2010 From: pushkar at ipvideosys.com (Pushkar Pradhan) Date: Mon, 30 Aug 2010 13:31:44 -0700 Subject: [Live-devel] Getting the FPS at the client side References: <007c01cb4864$e0e514b0$a2af3e10$@net.il><5358224A8253E24D8D8E7FA9244E5407B5BE86@ipvmail.ipvideosys.com> <008b01cb4873$7ac375a0$704a60e0$@net.il> Message-ID: <5358224A8253E24D8D8E7FA9244E5407B5BE87@ipvmail.ipvideosys.com> ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Sagi Ben Moshe Sent: Mon 8/30/2010 11:45 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Getting the FPS at the client side Hi Pushkar, I would like to know if the stream is NTFS or PAL, we can do it by the size but we prefer to do it by the FPS. As I was written, we are also writing the server part using Live555 so just let me know where should I add it inside the server. Thanks, Sagi Hi Sagi, You can take a look at RFC 4566. Perhaps this is what you are looking for: a=framerate: This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values using the notation "." are allowed. It is a media-level attribute, defined only for video media, and it is not dependent on charset. pushkar From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Pushkar Pradhan Sent: Monday, August 30, 2010 9:04 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Getting the FPS at the client side ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Sagi Ben Moshe Sent: Mon 8/30/2010 10:00 AM To: live-devel at ns.live555.com Subject: [Live-devel] Getting the FPS at the client side Hi Ross, At the client streamer, when I get a video link (Mpeg4 or H264) I get a set of parameters but the subsession->videoFPS() (frames per second) is set to zero. How can I get the Fps of the video link? We use Live555 as our server to stream from real video source (h264 or mpeg4). Maybe we should set something at the server side? Thanks, Sagi Hi Sagi, I don't think you can always get the FPS from the SDP, i.e. it is not mandatory to set the fps in the sdp. For some codecs this info might be available in the bitstream itself. What do you plan to do with the FPS? By the way you can always estimate it in your sink. pushkar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 7416 bytes Desc: not available URL: From finlayson at live555.com Mon Aug 30 21:22:08 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Aug 2010 21:22:08 -0700 Subject: [Live-devel] Getting the FPS at the client side In-Reply-To: <007c01cb4864$e0e514b0$a2af3e10$@net.il> References: <007c01cb4864$e0e514b0$a2af3e10$@net.il> Message-ID: >At the client streamer, when I get a video link (Mpeg4 or H264) I >get a set of parameters but the subsession->videoFPS() (frames per >second) is set to zero. As others have noted, this is not always present in the stream's SDP description. >How can I get the Fps of the video link? In general you will need to decode the video stream - at least, decode it enough so that you can figure out which received data contains the start of video frames. And then, from this - plus the presentation times - you can figure out the frame rate. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From samparknisha at rediffmail.com Tue Aug 31 05:47:51 2010 From: samparknisha at rediffmail.com (Nisha Singh) Date: 31 Aug 2010 12:47:51 -0000 Subject: [Live-devel] =?utf-8?q?Problem_in_streaming_h263_video_data?= Message-ID: <20100831124751.37302.qmail@f6mail-144-135.rediffmail.com> Hi, I am facing some problem in streaming a raw h263 file through live555. The client used is vlc player. - One problem which has been observed is that the video is getting played slowly, foe e.g. if the duration of video is 1 minute then it is getting played for 1 min 6 seconds. - The other problem being observed is that if the a person has come very near to the camera, then that part of the video plays very fast. I am not able to identify the reason of this issue. Please suggest how can this be avoided or what needs to be done to play it properly. Thanks and regards, Nisha -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 31 11:11:37 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 31 Aug 2010 11:11:37 -0700 Subject: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client In-Reply-To: References: Message-ID: >I am using the RTSP server functionality of the LiveMedia library, >and I might have resolved a client session management issue. The >senario is when a ServerMediaSubsession is shared >[reuseFirstSource=True] and clients choose RTP-over-TCP for >streaming mode, only the last requested RTP-over-TCP >RTSPClientSession can be torn down. All of the objects under the >ServerMediaSession will be runaways. The MediaSink keeps playing, >and the RTPInstance writes with socket error. The stderr shows >socket write attempts after all of the RTSP clients are closed. > >I am trying to limit the scope of the impacted code, and there seems >to be two area in the RTPInstance.cpp that are contributing to the >problem. #1, The >RTPInterface::setServerRequestAlternativeByteHandler() function is >overwriting the handler and clientData of an already assigned >SocketDescriptor object. It makes all existing socket descriptor of >the server media subsession to map to the latest RTSPClientSession >instance. #2, When RTCPInstance::addStreamSocket() function adds a >new stream channel, the RTPInterface::stopNetworkReading() function >calls deregisterSocket() and wipes out the existing SocketDescriptor >to RTSPClientSession mapping. Therefore, only the last newly added >SocketDescriptor has a valid fServerRequestAlternativeByteHandler to >notify of RTSP TEARDOWN command. At first I didn't pay much attention to this email, both because you were (at first) working with an old version of the code, but also because you were using a "@hotmail.com" email address, which serious professionals do not use. (If you want to be taken seriously on this mailing list, then you should not use "@hotmail", "@yahoo", "@gmail"-type addresses :-) But your analysis of the problem was exactly right. I have now installed a new version of the code (2010.08.31) that should, I hope, fix this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yinhua.li at siemens.com Tue Aug 31 23:11:03 2010 From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S) Date: Wed, 1 Sep 2010 14:11:03 +0800 Subject: [Live-devel] Set max connection number Message-ID: <68D227E48F4B0F4EB6161523402601BE76E89D@PEKW987A.cn001.siemens.net> Dear All, Does Live555 support setting maximum connection number? If we set 5, the 6th connection request will be refused. Can I get active connection detailed information(includes each client IP address)? Best regards. -------------------------------------------------------------- ??? Li Yinhua SIEMENS Siemens Ltd., China Nanjing Branch Corporate Technology Development Center (CT DC), Nanjing ?????????????37??????????211100? Tel.: +86 (25) 51171864 Fax: +86 (25) 51171761 Mobile: +86 15895967085 www.siemens.com P Save a tree. Don't print this e-mail unless it's really necessary. IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person. In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????Tell us???????www.siemens.com.cn/compliancehelpdesk -------------- next part -------------- An HTML attachment was scrubbed... URL: